Time to plan a software project? It’s not rocket science yet even NASA uses project planning software The recent landing of the Mars rover Curiosity was a sight to behold. The landing sequence looked like something straight out of a science fiction movie. The rover traveled millions of miles to reach its destination and then plummeted at enormous speeds towards the surface of Mars. The transport vehicle that held the rover then hovered above the Martian surface and released its precious cargo, which then gently touched down on this alien surface. Absolutely amazing!
Then there was the Mars Observer. This was an attempt to study the surface of Mars, magnetic fields, atmosphere, and climate. Unfortunately, in August 1993 NASA lost communication with the satellite. Despite repeated attempts to reestablish communication, the mission was considered a failure due to never being able to connect with the satellite again.
Both of these missions required an extraordinary amount of research, planning, and implementation. Yet, one fell far short of its intended purpose and the other is just beginning to uncover untold discoveries. Have you experienced similar results with software projects that you are responsible for managing? One software project may be a wild success and the other may come up wanting. What causes this difference and how can you plan a software project that is successful?
How to Plan a Software Project that Works
To successfully plan a software project you must invest time up-front. There are many various activities that you can invest your time on when it comes to planning a software project, the following list provides some insight into how to plan a software project that works:
Identify ALL Users
The emphasis here is on ALL users. In addition to the direct users, there is going to be a multitude of indirect users. There will be those who use the software every now and then to get their jobs done. There will also be those who receive or benefit from the results of the application. For example, management may use certain reports that the application generates. Make sure to include them in the requirements gathering session even if they don’t use the program directly themselves.
I learned a huge lesson many years ago when it came to learning to plan a software project and identifying users. I thought I had identified everyone that had anything to do with the application…and I had uncovered a multitude of people. But, there was one fellow in the deep recesses of the store where the software was being implemented that I missed. This fellow was discovered as the software began to be rolled out across various stores. This was a subject matter expert that brought the entire roll-out to a grinding halt because it did not include certain functionality that he thought (and others like him) was mission critical. Make a list and check it twice! Be sure you have anyone and everyone involved in the requirements gathering process as possible.
Identify their Credibility
A word of caution when you create the list from above when it comes to learning how to plan a software project. It is absolutely vital that you establish the credibility of those who are providing input into the plan. True story…we had a team that just went into a requirements gathering session where all the stakeholders had been identified. There was some great feedback coming back from the users, but then there was one voice in the room that was providing general and generic feedback. “Make it better”, “It needs to be faster” or “It’s too hard to use” he would say. After continual feedback like this throughout the morning, we asked him for specifics. “Exactly what is it that needs to be better, faster or easier to use”, we asked. “I don’t know, I’ve never used the program”, he replied.This is an easy trap to get caught in when you are first starting out on how to plan a software project that works. Be careful to not go down the path of a user that is not offering real value for what needs to be included in the application. The example above is an extreme case, but there are times when someone will blurt out something just to have something to say. Make sure you get out what you would consider being real requirements and those that are just being thrown out.
At this point in the process of learning how to plan a software project, it’s important to capture every little thing that is thrown out there. You have identified the right audience and you are zeroing in on only those who have credible and meaningful contributions to make to the plan. Prepare a long list of everything that should be included with enough information about each item that you will know what it is for future reference.
This is the point of how to plan a software project that you begin to prioritize the list that has been identified above. The best way to do this is broken it down into 3 buckets: 1) Absolute must-haves (business can’t be done without this) 2) Nice to haves: business can be done without this, but this will make it easier 3) Everything Else: cosmetic or very minor changes or additions. You now end up with ideally a very short list of absolute must-haves that your team can begin working on.
Dig into the Details
You can now explore these absolute must-haves in greater detail. Ask questions about what this feature needs to accomplish in the software. Challenge assumptions. Always ask ‘why’ is this something that is important to include or to operate in a particular manner. This will provide you with enough detail of what needs to be accomplished that you can turn it into a project plan and communicate the specifics to your team.
Finally, when it comes to how to plan a software project that works, you must deliver. There are a ton of steps between planning and implementation, but if you have done your homework up-front and spent enough time in the requirements gathering stage the end result will turn out much better.
One note: If you have the luxury of having Business Analysts on your staff, then the work above is best left in their hands. They know how to identify and uncover those elusive little things called requirements that, if missed, can bring a project to a grinding halt. Many companies may not have this luxury and it falls into the hands of the Project Manager to make sure this work is complete.
There is much uncertainty in planning missions to Mars. Despite this fact, there are those projects that are wildly successful and delight everyone. You can have the same experience when it comes to planning your software projects. Take the necessary time upfront and save yourself a tremendous amount of time and disappointment later in the cycle.