We all know how hard it is just to win on the project. And by win I mean lead a successful project from start to finish. More than half fail according to most findings and surveys. And that's based mainly on.one or more of the big three success determiners... On time delivery, on budget delivery, and customer satisfaction. If someone said "can you cut the budget by 10%?”, you'd probably ask them to go get their head examined. If they asked you to deliver four weeks early, would you say the same thing? You would probably want to, but lets really consider how that might work, because there actually are some fairly straightforward ways to make it work and – unlike the budget cutting request - if you're the business analyst helping the project manager come up with a way to deliver four weeks early, there are some ways of making this happen that may even result in extra revenue for the delivery organization.
To deliver a product early you have likely four major options. If you think of something I'm missing, please comment and let's discuss, but I see four major options.
Add more bodies. You can always add more resources to the project in an attempt to get work done faster, often with disastrous results. While it may speed work and task progress and completion up to some degree, it will certainly not do so exponentially or even lineally. Not sure I'm saying that right but here's what I mean... increasing your project delivery tech staff from 5 to 10 resources will not cut your task completion time in half. In fact it may not help – it depends on the team, the new resources, and the complexity of the project and the issues at hand. There is always a learning curve and work could even be missed in the transformation process. Certainly it has the potential to add significant – possibly enormous – costs to the project so don't go this route lightly and I hesitate to ever go this route without a big change order in hand to cover all of the additional project hours (and I try NOT to be conservative in my estimates).
Remove work from the plan. As the business analyst, you can assess the project landscape and work with the project manager to figure out what, if any work or task clumps can be removed from the project plan. Perhaps there are some tasks that contain work not really necessary to the outcome of the project. I don't advise shortening or eliminate deliverable reviews, but some technical development work can be eliminated if the customer can be talked out of an entire deliverable. Yes, the project revenue will drop, but if the customer needs the project completed earlier, there are probably a few things they will now consider eliminating from the project effort. Look for the logical stuff and start cutting.
Move non critical work to a post deadline phase. Just as above where the business analyst and project manager may be able to sit down and remove non-essential things from the project schedule to help shorten the delivery timeline, likewise they can do essentially the same thing while keeping the projected project revenue the same or even increase it through change orders. Move the tasks and / or deliverables that are not essential to the solution that is needed on 'x' date out to a later date and either make that work a separate project or make it a later phase that gets delivered after the initial, newer deadline is reached.
Halt work, refocus on the necessary. This is a more drastic version of what I just covered. In this scenario you completely stop work and brainstorm on what needs to happen in the time left in order to get the functionality needed by 'x' date out the door and to the awaiting end users. It's more complex and more risky, but if the date is close it may be the necessary route to go. The resulting change orders will probably be even higher because there is no way you can completely stop work, plan, basically kickoff a new phase to get critical work up and running, then revisit the remaining work without adding some significant effort and hours to that remaining work. Again, a win-win... especially if it works. If you were on track with delivery in the first place, and you're getting very close to the new deadline, then this drastic move – if handled successfully – will solve a big client need, keep them very happy and bring in more revenue for your organization. It can end up being a huge success story if handled properly.
Summary / call for input
When the project is running smoothly and delivery looks like it's going to happen on time and on budget (yes, a rare thing indeed!)... everything seems right in your little PM world. You planned well, you executed flawlessly, you liaisoned with project manager and tech team with perfection and it's all falling into place. Then, the customer says “can we move the delivery date up a month?” and all heck breaks lose. You want to do everything possible. You never want your knee jerk reaction to be “no.” The last thing you want to say quickly to a customer is “no.” What if you can “fake it till you make it” on something that seems out of your scope? What if you may be saying “no” to a $100,000 potential change order? Always say “yes” or “probably” and explore it further. But a request for an earlier release date can often be a very painful thing and nearly impossible to accommodate without moving or eliminating some work. You won't figure it out in an afternoon or overnight. Take your time and plan well. Poor planning can result in lost – rather than gained – revenue and profitability.
Readers – what are your thoughts on this subject? Have you ever been asked to move up a release date on a project for whatever reason? How did you respond? What steps did you take to make it happen – or to try to make it happen? Were you successful? Please share your experiences and discuss.
To deliver a product early you have likely four major options. If you think of something I'm missing, please comment and let's discuss, but I see four major options.
Add more bodies. You can always add more resources to the project in an attempt to get work done faster, often with disastrous results. While it may speed work and task progress and completion up to some degree, it will certainly not do so exponentially or even lineally. Not sure I'm saying that right but here's what I mean... increasing your project delivery tech staff from 5 to 10 resources will not cut your task completion time in half. In fact it may not help – it depends on the team, the new resources, and the complexity of the project and the issues at hand. There is always a learning curve and work could even be missed in the transformation process. Certainly it has the potential to add significant – possibly enormous – costs to the project so don't go this route lightly and I hesitate to ever go this route without a big change order in hand to cover all of the additional project hours (and I try NOT to be conservative in my estimates).
Remove work from the plan. As the business analyst, you can assess the project landscape and work with the project manager to figure out what, if any work or task clumps can be removed from the project plan. Perhaps there are some tasks that contain work not really necessary to the outcome of the project. I don't advise shortening or eliminate deliverable reviews, but some technical development work can be eliminated if the customer can be talked out of an entire deliverable. Yes, the project revenue will drop, but if the customer needs the project completed earlier, there are probably a few things they will now consider eliminating from the project effort. Look for the logical stuff and start cutting.
Move non critical work to a post deadline phase. Just as above where the business analyst and project manager may be able to sit down and remove non-essential things from the project schedule to help shorten the delivery timeline, likewise they can do essentially the same thing while keeping the projected project revenue the same or even increase it through change orders. Move the tasks and / or deliverables that are not essential to the solution that is needed on 'x' date out to a later date and either make that work a separate project or make it a later phase that gets delivered after the initial, newer deadline is reached.
Halt work, refocus on the necessary. This is a more drastic version of what I just covered. In this scenario you completely stop work and brainstorm on what needs to happen in the time left in order to get the functionality needed by 'x' date out the door and to the awaiting end users. It's more complex and more risky, but if the date is close it may be the necessary route to go. The resulting change orders will probably be even higher because there is no way you can completely stop work, plan, basically kickoff a new phase to get critical work up and running, then revisit the remaining work without adding some significant effort and hours to that remaining work. Again, a win-win... especially if it works. If you were on track with delivery in the first place, and you're getting very close to the new deadline, then this drastic move – if handled successfully – will solve a big client need, keep them very happy and bring in more revenue for your organization. It can end up being a huge success story if handled properly.
Summary / call for input
When the project is running smoothly and delivery looks like it's going to happen on time and on budget (yes, a rare thing indeed!)... everything seems right in your little PM world. You planned well, you executed flawlessly, you liaisoned with project manager and tech team with perfection and it's all falling into place. Then, the customer says “can we move the delivery date up a month?” and all heck breaks lose. You want to do everything possible. You never want your knee jerk reaction to be “no.” The last thing you want to say quickly to a customer is “no.” What if you can “fake it till you make it” on something that seems out of your scope? What if you may be saying “no” to a $100,000 potential change order? Always say “yes” or “probably” and explore it further. But a request for an earlier release date can often be a very painful thing and nearly impossible to accommodate without moving or eliminating some work. You won't figure it out in an afternoon or overnight. Take your time and plan well. Poor planning can result in lost – rather than gained – revenue and profitability.
Readers – what are your thoughts on this subject? Have you ever been asked to move up a release date on a project for whatever reason? How did you respond? What steps did you take to make it happen – or to try to make it happen? Were you successful? Please share your experiences and discuss.
RSS Feed
