Adapting a Microsoft Project mind to a JIRA world

Over the last two years I have been steadily transitioning from project based, hardware-centric systems, to the world of software development. This transition has required me to adapt in many ways, some were easy and some were quite difficult. As I prepare for the Atlassian Summit in San Francisco this week I am reminded of the journey my mind, priorities, work habits, and expectations have made this last two years.

First and foremost, the people are quite different. Network Engineers and Audio Visual Techs tend to work on short term projects (relative), and they are expected to bring a system to a point of completion that is concrete in nature. The system needs to simply run with only user input. Their minds are focused on wrapping up every loose end, labeling every connection, locking down configurations, essentially sealing the system in a sort of capsule. They need to move on to the next project and follow the same process there. It is the nature of the business. It is the rare system that can afford to have one or more staff constantly tweaking and improving the system in perpetuity.

Software Developers live in a world of incompletion. Sure, there are regular feature deliveries, bug fixes and the like. But software is simply never finished. This industry is not for those who are easily frustrated. Where I see a solid sense of urgency in a good network engineer, I see an almost maddening patience with the software developer. There is certainly room for a sense of urgency and a desire for completeness in the software industry. In fact, the preeminent developers I know understand WHEN to switch into an urgent, completion focused mode. Much the same that a truly preeminent network engineer knows when to relax and not panic in the midst of project chaos.

Work habits and team expectations are also radically different. In a network installation, almost every aspect is known prior to the kickoff of a project. You have completed a network diagram, acquired all the hardware needed, the gameplan is ready. The focus is on execution, documentation, efficiency, and quality. Essentially you have a 95% understanding of what you will face during the project.

On a software project it is much more of a journey. You know how the system needs to interact with data and users. You know the technologies you will use (mostly). If you are fortunate you have a fairly good understanding of the components that will go together to make the system work as specified. It is expected that many challenges will be faced in the process. Problems to solve, approaches to choose, and compromises to be made. In all honesty there is roughly a 25% understanding of what you will face during the project.

Throughout my career Microsoft Project has been a go-to tool for me through thousands of projects large and small (wow, I feel old). When I was first charged with managing some projects in software, I immediately leaned on this old familiar tool. The reality was quickly apparent, it was useless for the management of software projects. There is an expectation using Project that you can map the vast majority of the implementation and use its tools to manage the project. I am sure there are plenty of people who have successfully forced this square peg into the round hole. I quickly realized I needed a new approach.

Very early on I was pointed to JIRA by Atlassian software as the leading solution in the space. It took us over a year to decide to pull the trigger and implement, but we got many processes in place in preparation of the move. I have now been working for the last month to set the system up for our team.

The tools and systems are specifically built for workflow, not project completion. There are “micro-projects” where completions occur, but the focus is on managing the work coming in, breaking it down into manageable pieces, and getting them done. I love the swim lane analogy used by the software, it is very analogous to the feel of the software projects.

I will close with an analogy I found very appropriate. Completing a hardware based project is like a hike across town. You know your destination, you can see the path, the obstacles, the spots you will rest along the way. Sure, a big bloke with a club could jump from behind a building and attack you, but you will likely see him coming. Completing a software project is like swimming across a channel. It looks straight forward to an observer but you never know what is lurking under the surface. The process is much more fluid and changing.

I am heading out for some intense training at the Atlassian Summit. It is a very exciting time, one that I have been preparing my mind for these last two years.

4 Comments

  1. Greg Lamberson July 28, 2012 at 11:45 AM #

    Nice read. Like it.

    Long time no see, Mike. Hope you’re well.

    Greg

Trackbacks/Pingbacks

  1. JIRA Training 102 – The Little Things | Michael McNeil - March 12, 2014

    […] Other JIRA Articles: JIRA Training 101 – Workflows Using JIRA – Be a Winner not a Loser Adapting a Microsoft Project mind to a JIRA world […]

  2. JIRA Training 103 - The Right Tool - The Oasis Digital BlogThe Oasis Digital Blog - September 19, 2014

    […] JIRA Training 102 –The Little Things  JIRA Training 101 – Workflows Using JIRA – Be a Winner not a Loser Adapting a Microsoft Project mind to a JIRA world […]

  3. Atlassian Summit 2014 – The Right Tool | Michael McNeil - October 20, 2014

    […] JIRA Training 102 –The Little Things  JIRA Training 101 – Workflows Using JIRA – Be a Winner not a Loser Adapting a Microsoft Project mind to a JIRA world […]

What Do You Think?