9 Project Management Commandments to live by

I'm coaching a very successful software company in Auckland on the finer points of Project Management.  The 9 commandments that follow represent an accumulation of wisdom that has served me well over the years.  Please feel free to share your thoughts on the matter.

1. Begin with the end in mind

• Plan the flight... then fly the plan
• Pause for agreement and clarity before implementing
• Stay wedded to the outcome, not the path for getting there
• The worst time to define success is after it’s over
2. Manage by result, not activity
• An active team is not necessarily a productive team
• Focus on Throughput
• Limit Work in Progress
• Learn to use teams to achieve results... not individuals.
3. Compromise on scope not quality
• Define ‘quality’ upfront (e.g. verification criteria)
• Understand technical debt
• Learn to recognize an ‘interest’ payment from a ‘capital’ payment. (i.e. treat causes as well as effects)
4. Escalate early and often (e.g. 2X2X2 Escalation)
• 2 minutes to explain the issue
• 2 minutes to describe options
• 2 minutes to make a decision on what to do next
5. Continuous Course Correction
• Invest in short regular planning exercises.
• The act of planning is more valuable than the plan!
• Learn to surface impediments/blockers regularly
• Planning exercises are for planning the work not doing the work!
6. Serve your team
• Enable your teams with clear decisions, clear priorities and lot’s of encouragement
• Double the rate of failure!
• Trust your experts
7. Manage the context
• Maintain situational awareness outside of the team
• Make yourself aware of ALL the stakeholders
• Create an atmosphere that celebrates failure as a learning experience
• Communicate little bits of news often!
8. DWYSYWDWYSYWDI
• Credibility is critical to building trust
• Do What You Said You Would Do When You Said You Would Do It .
9. Retire risk early
• Tiger cubs are easier to deal with than tigers!
• Prioritize first... sequence last.

How can corporations best fight atrophy?

I was listening to a podcast a while back* by Ried Hoffman (who started LinkedIn and Paypal) and something he said got me thinking about corporate atrophy**.

Ried mentioned how easy it was for Paypal to out maneuver the larger banking bodies during the startup phase. They were busy testing the legal definition of a bank with their online offering and the banks were squirming and nearly powerless to respond. In fact some of the banks online counter offerings took in excess of 12 months to deliver... as Ried correctly points out, thats an eon in internet time!

Just how did the banks get to this lethargic state?

And how can they (or any large corporate body for that matter) hope to compete in this rapidly changing business environment.

More to the point, How can corporations best fight this atrophy?

*For Rieds Podcast: http://edcorner.stanford.edu/authorMaterialInfo.html?mid=1650 
** Definition of atrophy: http://www.thefreedictionary.com/atrophy

I posted this question in LinkedIn and got quite a few interesting suggestions back:

Mergers & Acquisitions
>>Let others take the big risks and buy them up when they look promising.

Various forms of Internal Entrepreneurialism
>> Google have an interesting internal policy where they allow thier employees to use 20% of their worktime to work on anything they want. They have enjoyed an enormous amount of success from the projects resourced this way.

9 Top Tips for starting an Agile Project

1. Set-up a planning session with the project sponsor... get them to share the vision... identify  the Success Criteria (I.e. the conditions under which the vision will be considered realised)
2. Use Rob Thomsett's project success sliders to define the degree of flexibility in the different dimensions.
3. Derive SMART Objectives (Specific, Measurable, Achievable, Realistic and Timely)
4. Create a Product Breakdown Structure
5. Turn this into a Product Flow Chart and use this to communicate the project roadmap to both the team and the sponsor.
6. Use Mike Cohn's planning poker to estimate the relative weighting for each of the main products on the roadmap.
7. Establish a burndown chart to track 'speed over ground'.
8. Propose that your project sponsor gives the status reports on the project.
9. Re-plan the project regularly.  Keep checking that the project goal is still the same (i.e. progressive elaboration)

Handling 3rd party vendors on SCRUM projects

A friend of mine recently asked me what the best way was to manage a 3rd party vendor on a SCRUM project. (SCRUM is an Agile Methodology for those of you who don't know)

Here's the advice I gave him:

Get the vendor relationship off to a healthy start:

• Make sure there's an open, honest and safe channel for the vendor to communicate with you.
• Be as specific as possible with what you require from them. Try and be results focused and not activity focused. Here's a great article by Marc McDonald on the merits of results versus activity management.
• Urge vendors to give commitments that you can rely on and not commitments that you may want to hear.
• As a rule of thumb question the assumptions behind an estimate and not the estimate itself. This way your vendor is encouraged to use their expertise while protecting their self esteem (improves their perception of safety).
• Try and use the language of 'confidence' when considering estimates. For example, "The vendor is very confident in a 5 day delivery" or "The vendor is not very confident in a 5 day delivery due to an issue with XYZ". This way you're less likely to set unrealistic expectations with stakeholders.
• Ask your vendors to escalate potential issues early and often... better to handle things early & cheap than late & expensive. (See my previous blog article on this)
• Work hard to empower your vendor... especially since their performance has direct impact on your reputation. In other words, your reputation will very likely take a knock if they flounder.
• Prioritise the deliverables you're expecting as much as possible. Be clear about Must Haves.
• Compromise on Scope not Quality where possible. Don't make them deliver things if it can't be done properly. For example if you're time pressured, negotiate with scope.

Integrating vendor deliverables with your SCRUM project:

• Create a user story card for their deliverable and place it in the product backlog.
• When the iteration arrives be sure to schedule integration and testing tasks in the sprint backlog to ensure the vendor deliverables are truly DONE by the end of the iteration.
• For planning poker, Limit the task estimates to just those your team will need to carry out. I.e. exclude any work your vendor will do as this will distort your view of velocity (... thanks Vasco)
• Invite your vendor along to attend the sprint planning meeting for the relevant iteration. A public commitment to the team to meet a deadline is always more powerful than a contract ;-)
• Be sure to regularly ask vendors how they are tracking and to confirm their delivery estimates (weekly should be ok).
• If there are dependancies on the vendor's work be sure to assess the impact of delays. Communicate the potential impacts to stakeholders early.
• The vendor should also attend the sprint review to see how their deliverable has been integrated and to clarify anything should the need arise.
• It's also ideal to have your vendors attend the relevant sprint retrospective to get their input.

Plan to succeed on projects (Part 2)

Now that you've planned the flight... Fly the plan.

If you've taken the advice given in Part 1 you should be set up to drive your projects by result rather than activity... you'll find your team responds best to this approach...

I posed a question on LinkedIn recently to see what advice the professionals would give a budding PM:

"What are the top 5 tips you would give a PM to improve their luck on projects?"

I chose a couple of these answers as they sum up the basic principles of flying the plan nicely:

Here's the answer offered by Gianluca Bacca:

1) Define the scope of you project as clear and as soon as possible and formalize it … a project doesn’t exists without a Project Charter and a WBS!

2) Be realistic and pragmatic, don’t forget that generally available resources are limited … a request or change coming from a stakeholder, generally, involves a trade-off between different elements of the “triple constraint” (time, cost & quality) … think always in terms of trade off between the elements of the “triple constraint”.

3) Manage ALL your stakeholders with care being proactive: to do this you need to identify ALL of them and constantly communicate with ALL of them

4) Identify all risk of your project and constantly looking for their evolution along the entire lifecycle of your project … don’t forget risk! In Project Management luck and bad luck doesn’t exist (more or less) … there are mainly identified and unidentified risks! Identifying risks you can build your luck by yourself ;)

5) Don’t forget to collect lessons learned after each project … you cannot improve your ability to manage your future projects without lessons learned from your past projects ;)


This is my favourite answer from an old colleague, Gunveer Mahandru:

1. Show leadership (strong vision, direction. take risks, manage them)
2. Develop a backbone (back up what you say, don't wilt and wimp)
3. Work the team dynamic (manage the form/storm/norm/perform phases)
4. Engage stakeholders and keep buy-in (politics with a small 'p')
5. Inject entrepreneurship (excite, motivate, innovate)

Short, sharp and very effective...

Here are a few more useful little project tips:

Derive a burndown chart and use it to generate momentum and track progress.
- use Mike Cohn's estimation technique, planning poker.
- derive the ordered stack and begin plotting this over the time line.
- You may want to include checkpoints (or iterations) in the plan. (Step towards Agile)
- use these checkpoints as opportunities to deliver value (no matter how small) and plot your position on the burndown chart.
- Remove products from the stack when considered 'done'.
- 'Done' = when someone other than the developer (preferably the recipient) says it is... i.e. it meets the predetermined acceptance criteria.

In fact, I'd heartily recommend you watch Mike's YouTube clips on Agile Estimation: Part 1 and Part 2

A short note on lightweight reporting:
Agree a '5 minute emergency channel' with the sponsor... As you become aware of an issue which significantly affects the project, present what you know to the sponsor (no interpretation) along with a few proposed next steps. Aim to present and get a decision within 5 minutes... Even if the next step is to have a longer meeting. This way you keep your sponsor in touch.

Good luck!!

Plan to succeed on projects! (Part 1)

You've heard the old saying: "Plan the flight then fly the plan..." well I'd like to apply this approach to project management in this article and offer an formula that will ensure you're driving the project by result rather than activity.




Here we go:


Step 1) Find a sponsor. Note: If you haven't got a sponsor... get one... don't give in to the temptation to implement your own vision. If you're the sponsor then ideally get someone else to deliver your vision ;-)
Step 2) Talk to the sponsor about their dream... replay your interpretation at every opportunity. Especially the benefits they expect.
Step 3) Once you've gained a bit of rapport start talking about: scope, success criteria, time scales.
Step 4) Go away and think about the objectives and resources you'll need.
Step 5) Propose the set of highlevel project objectives and negotiate for resources.
Step 6) Develop a product breakdown structure... Derive the Product Flow Chart that follows.
Step 7) Market this to the team and sponsor as the delivery roadmap, make sure the roadmap attacks the highest risk/reward items first.
Step 8) In closing, make sure you're set up to drive the project by result not activities!

By this stage, you should have enough to get a green light to proceed. So there you have it... the flight plan.

In part 2 we'll look more closely at flying the plan...