1. Projects always have problems
2. The earlier you identify problems, the sooner you can work on solutions
3. People who tell you that their projects have no problems are lying
This advice has always worked for me so I reserve a section in my status report for problems or issues.
 |
| Colin Powell's latest autobiography |
This week I'm reading Colin Powell's latest book: 'It worked for me.' Lots of great leadership advice in there.
He addresses problems in Chapter Six:
"If your desk is clean and no-one is bringing you problems, you should be very worried. It means that people don't think you can solve them or think you don't want to hear about them. Or, far worse, it means they think you don't care. Either way it means your followers have lost confidence in you and you are no longer their leader."
What do you guys think of this advice?
Thanks Abarshini. Glad you liked it.
ReplyDeleteBruce
wow,, Great Post.
ReplyDeleteProject Management Training
Thanks Kiruthi.
DeleteHave you every been on a project without problems? It's funny how many people think that a properly planned project should be problem-free.
Your post is spot on, but your comment got my attention. Projects that are problem-free are too good to be true. If this happens, you either have exceptional team members or you’re overlooking metrics. Digressing a bit, I just want to know the techniques you use to effectively gauge the success of your projects. I’m looking forward to your response, Bruce!
ReplyDeleteGood question Wilber!
DeleteI gauge success on a project using a few different variables. I start with the six constraints on the project:
1) Cost. Did I stay on budget or not? I use Earned Value reporting for this.
2) Schedule. Did I stay on schedule? My Gantt chart is my friend here. I gauge how I did on project end date, key milestones and all deliverables.
3) Scope. Did my project deliver the scope I originally planned? Here I compare the actual deliverables against the requirements.
4) Quality. Do the deliverables possess the expected level of quality? I compare the results of measurements against the specifications.
5) Risk. How well did my project predict and adjust for risks on the project? I use the Risk Register and compare it to the Issue Log generated throughout the project life. Often there are risks that we hadn't planned for or risks that turned out better or worse than we had hoped.
6) Resources. How stable was my team and how much were they needed compared to our plan? The answer to this is achieved by reading between the lines on status reports and interviewing people as the project progresses and at lessons learned sessions.
After these project constraints have been considered I feel it useful to conduct a Staholder Review. How well did my stakeholders think the project went? Was the customer satisfied? Was my Sponsor happy? Will my team-mates want to work with me again on another project? Will Functional Management let me use their prople again?
I hope this answers your question.
Bruce