Making Good Project Decisions – Part 2
Posted by Brad EgelandIn Part 1, we discussed the first three of seven general questions that you can ask yourself
and review with your team when making significant decisions on your projects. In Part 2, we’ll continue down this path and examine four additional questions to consider as part of your overall decision-making process in your efforts to make the best possible decisions for your project, your team, and your customer.
What is the window of opportunity?
If the building is on fire, no matter how complex choosing your route of escape might be, there is only a set amount of time that your decision will matter. If you wait too long to make the decision, it will be made for you; routes will close and all options will go away eventually. The way the universe works is that big decisions don’t necessarily come with greater amounts of time to make them. Sometimes, you have to make tough strategic decisions quickly because of the limited window of opportunity you have. And sometimes, the speed of making a decision is more important than the quality of the decision itself.
Have we made this kind of decision before?
There is no shame in admitting ignorance: it generally takes courage to do so. If you’re working on anything difficult or cutting edge, there will be times when you have no idea how to do something. Don’t hide this (unless you’re choosing speed over quality for the decision in question), or let anyone else hide it. Instead, identify that you think the team, or yourself, is inexperienced with this kind of choice and might need outside help, or more time, to think through the problem. If a leader or manager admits to ignorance, she makes it OK for everyone else in the room to do the same. Suddenly, decision making for the entire team will improve dramatically because people are finally being honest.
Making Good Project Decisions – Part 1
Posted by Brad Egeland
Everything you do every day is a kind of decision: what time to wake up, what to eat for breakfast, and who to talk to first at work. We don’t often think of these as decisions because the consequences are so small, but we are always making choices. We all have our own natural judgments for which decisions in our lives demand more consideration, and the same kind of logic applies to project management decisions. Some choices, like hiring/firing employees or defining goals, will have ramifications that last for months or years. Because these decisions will have a longer and deeper impact, it makes sense to spend more time considering the choices and thinking through their different tradeoffs. Logically, smaller or less-important decisions deserve less energy.
So, the first part of decision-making is to determine the significance of the decision at hand. Much of the time, we do this instinctively; we respond to the issue and use our personal judgment. Am I confident that I can make a good decision on the spot, or do I need more time for this? It often takes only a few moments to sort this out. However, this is precisely where many of us run into trouble. Those instincts might be guided by the right or wrong factors. Without taking the time, at least now and then, to break it down and evaluate the pieces that lead to that judgment, we don’t really know what biases and assumptions might be driving our thinking (e.g., desiring a promotion or protecting a preferred feature).
With that in mind, here are some core questions to consider when evaluating a decision. This list can be used in the moment to help size up a specific decision, or as a way to re-evaluate your high-level criteria for sizing up decisions.
A Project Completion Checklist
Posted by Brad EgelandAs the project comes to closure, it’s time to look back and enjoy all the successes you’ve
experienced on the project. All the memorable learning moments and all of those leadership situations that have allowed you to grow as a project manager. Not! As the project comes to closure, you’ll usually find yourself knee-deep in administrative and signoff tasks not to mention work related to those tedious remaining issues that make the customer very nervous at deployment time.
Your duties as project manager and leaders extraordinaire certainly don’t cease … they actually increase. You’re dealing with lots of things going on at once and you’re also dealing with two separate sets of team members – yours and the customer’s – who are being pulled by their respective organizations to free themselves up for new and exciting projects. They’re working in shutdown mode and it’s difficult to get the productive hours out of them for YOUR project right now. It can take all of your resource management skills just to keep team members engaged.
Customer Issues
- Complete all deliverables
- Install and test deliverables
- Prepare operating manual
- Prepare maintenance manual
- Train customer’s personnel
- Agree on level of follow-up support
- Conduct formal acceptance review with customer
- Verify customer satisfaction
Facing Challenges at Closing Time
Posted by Brad EgelandEven the smoothest running projects will face challenges as they move toward closeout.
You know the scenario …. you and your team have faced your fair share of issues on the project – no project is without issues and rough spots. But for the most part, things have progressed rather well. Even user acceptance testing went off without too much of a hitch.
Now you’re almost ready for implementation, and post-deployment activities and things are becoming harder to control. Why? This should be the easy part, right? I call this the ‘Steve Blass Syndrome’ of project management (after the 1960’s and 1970’s Pittsburgh Pirates pitcher who was very good and then suddenly couldn’t get the ball over the plate – ok, so maybe I’m the only one who remembers him….). So why would things suddenly become difficult so close to the end of successful project?
Here are a few reasons why this is often the case…
Technical Challenges
- Start-up problems with new products or new designs
- Thorough identification and agreement on all remaining deliverables
- Loss of control of the charges to the project as things are winding down – people start doing ‘whatever it takes’ to get through the final push often damaging the project budget
- Hand-off issues in transition to tech support
Is Project Cancellation Always Bad?
Posted by Brad Egeland
Having your project canceled sounds like such a horrible thing. A career killer. But, as strange as it may sound, this is a situation that should actually happen more often than it does. There’s a good reason why this is true. Projects are investments that your organization makes, from which they expect a return. In real life, investments can sometimes go bad.
The same thing can certainly apply to a project. Conditions can change in such a way that the project ceases to become the winner it seemed to be at the outset. Simply stated, management no longer expect the project to have the business impact required to make it wise to keep spending money on it. In many cases, a project such as should be terminated, though in far too many cases, it isn’t.
There are at least three reasons why early project termination usually doesn’t occur, even though it should:
Plodding ahead
You should be testing project viability—or financial justification—on a continuous basis throughout the life of the project. Some organizations don’t do this very well. Others don’t do it at all. Once management approves a project, it simply moves ahead until it’s completed. In today’s fast-paced and constantly changing world, it’s always possible that there will be changes that undermine the original business case for the project. That means that you need to reconsider the economic viability of every project periodically. And the organization should terminate projects that have lost their business case underpinnings.