Project FAIL, Part 2: Hitting a Moving TargetPosted by Tim Ballard
In part 1 of this blog post I wrote about the most common reasons for project failure. In this post I will be discussing the challenges associated with “hitting a moving target”. In IT a moving target is a project that has been poorly scoped or not scoped at all and is constantly changing.
The “Iron Triangle” of Project Management is made up of project scope, time and budget, changes to one of the 3 points will inevitably affect the other two points. Increasing the scope of the project will affect the scheduled completion a date and raise the total project cost. If we ignore client requests for new features and continued with our original plan we may finish on time and within budget but have unhappy clients, which is unacceptable. If we add the client’s changes to the project but cut other features that were originally planned we may finish on time and within budget, but again we would have unhappy clients, also unacceptable. We could add all the clients’ new features while still completing the original planned work but we would likely finish past the original estimated completion date and over budget which once again will lead to unhappy clients which is of course, unacceptable. So how do we manage a project that is constantly changing?
It’s highly unlikely that clients will want less more their money. Just like any of us would, they want as much value as they can get for their dollar. Dealing with project changes typically means that you will receive several requests for features that were not included in the original project scope plan. How do we handle these requests, keep clients happy and maintain agency profitability? In part 1 of this blog post I wrote a small section called “Scope before Code”. The most common way to for projects scope to get out of hand is to have a misunderstanding of what features the project actually entails. Before development begins your agency must work with the client to gather all the project requirements, this ensures that both parties are clear on what will and will not be delivered. To make sure your project doesn't become a moving target here are some tips on how to effectively gather project requirements:
- Know your project stakeholders- Project stakeholders are the people inside your clients organization who are responsible for the project’s success or who have influence on project completion. Do your best to get everyone involved with the project together a few times before the project begins for joint application design meetings. If you don’t involve all project stakeholders in the design process from the beginning, your project will likely be subject to several changes that will affect the release date and budget.
- Focus on “what” not “how”- Software development is an extremely technical field, not all of your project stakeholders will be technical experts. Focus your meetings on eliciting their wants about the software you are designing, your questions should focus on the users of the software, not the developers. Try your best not to use technical jargon unless they ask you to.
- Don't assume anything- A sure fire way to not be on the same page as your clients is to assume what they want. If you are unclear on any aspect of what you are building, ask questions. Your agency is the expert in your respective field or you would not have been hired by the client. The client may not be able to describe exactly what they want until you ask the right questions.
Efficient gathering of project requirements ensures that both parties agree on what the project deliverables are. There will quite likely still be changes to your project over its lifetime but with the scope of the project defined you won’t be shooting at a moving target for the remainder of the project. Managing changes to your project is critical to project success. I will be going over how to manage customer change requests efficiently in an upcoming post. If you have any questions about how to manage your next project email or call me at 866-625-9034 ext. 2002.