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)

7 SCRUM insights from Jeff Sutherland and Jens Ostergardt

Jeff Sutherland, the inventor of SCRUM and Jens Ostergardt, the 1st SCRUMMASTER, were keynote speakers at the APN in Auckland last night.

Here are a couple of salient points I took from the talk:

• Jeff was a fighter pilot in Vietnam (Sydney 1967) and flew over 100 missions! This along with Jeff's subsequent experience in medical sciences seems to form the backdrop to the pre-scrum thinking. Jeff said he came up with a process that is in a constant state of response to impediments.
• Jeff appears to be a scientist at heart with an evidence based way of getting his point accross. One of the stats he mentioned was that an average 63% of features change on development projects... I'm still digging for the reference for this... will post it shortly.
• When coaching senior management teams Jeff seemd to emphasize the need to "surface impediments". He cited a great example of a Danish company that was level 5 on CMMI with excellent control over processes. This was used as the test bed for determining the productivity differences between SCRUM & Waterfall... needless to say SCRUM kicked ass ;-)
• Read the MIT iRobot story. I loved this story as it really brought home the need to establish the learning process with simple rules... The world is the database... simple rules give rise to sophisticated behaviours!!!
• Jens gave some valued advice for new ScrumMasters:

1. Don't get fired,
2. Resist the urge to 'help' the team
3. Don't use a SCRUM tool at first! (Help the team find it's feet (low tech) before introducing tools.)

• Jeff seems to enjoy applying Root cause analysis for SCRUM issues... Let the data reveal the causes. He gave one of his Polish companies as an example. The company in question had been advised to implement integration testing... this was ignored and later identified as a root cause of the ensuing spate of iteration failures.
• Lack of integration testing was identified as a major impediment to getting to DONE!

Hope you enjoyed this installment... If you attended the event too please feel free to add your own take on the talk!

This event was arranged by Edwin Dando from Clarus Consulting in Christchurch. A real win for the New Zealand Agile community I'd say!!

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.

3 Steps To Winning Over Your Most Difficult Stakeholder.

3 Steps To Influence Stakeholders on Prezi

An important part of a good Business Analyst's tool-set is the ability to engage and influence key stakeholders.

Here's a simple model I use to develop meaningful and lasting professional relationships with my stakeholders be they managers, project people or juniors:

Over a period of time (i.e. one or more meetings or interactions) make sure you move through the following phases:


Step 1: MATCH

• The main goal for this phase is to empathise as much as you can. In other words walk a mile in thier shoes.
  


• Actively demonstrate that you are working to understand their view of the world. Take opportunities to stop the conversation and "play back" what you've heard.



• Listen out for opportunities to add value in small ways. (e.g. mention an online resource that may be helpful for them)



• Whenever you interact be sure to mirror body language, tone of voice, language. Sounds cheesy but it works!

Step 2: PACE

• After you've practiced matching for a while you should be more 'in tune' with their way of thinking.



• Conversations should flow quite easily and your stakeholder should be quite relaxed.



• You should also have a good understanding of what they want or what thier concerns are.



• In this phase you focus on keeping the momentum going. Feedback things that you know they would be interested in.



• Make sure you keep any promises made in conversation even if it may seem trivial. (This is crucial for building credibility!!)



• You know you're getting this part right if you can finish their sentences!

Step 3: LEAD

• Be outcome oriented. Stay wedded to the outcome and not the method of getting thier!!!


• This is when you start bringing in your agenda in a very respectful way.
  
• Start by telling the reason for talking to them. Ask them for some time to explain your point of view.


• Be open to comments and treat questions or concerns with respect.


• Respond to comments as if you were looking at your message alongside your stakeholder.


• Ask them what they think the best way is to proceed.


• Respond to thier advice. Show that you are able to be influenced.

This model has served me well over the years and really helps remind me to listen before presenting.


If you're interested in where this model came from have a look at the NLP wiki.

M-Commerce: Did anyone see this coming?

The language of commerce has changed dramatically in the last two decades especially with the growing popularity of trading electronically.

However no-one could have predicted the popularity of the mobile phone and the subsequent form of commerce it has given birth to. Dubbed m-commerce, early adapting countries such as Japan and the U.S. are enjoying a massive surge from this channel and it's only going to get better.

The International Telecommunication Union published a recent report on global ICT statistics and it states that the number of mobile phone subscriptions now exceeds 4.6 billion... That's 67% of the world's population with a mobile phone!!! (http://www.itu.int/ITU-D/ict/material/Telecom09_flyer.pdf).

If you're formulating a strategy for the next ten years don't forget to check what kind of impact this will have. I'm giving my R&D team a call as soon as I get back in the office to ask whether they've got anything in the pipeline in m-commerce!

By the way, Wikipedia gives a great overview of the business applications of m-commerce.