I am very pleased to announce that this blog has been selected as a finalist in the PMI-SAC award for Project Management Literature.

The other entries include Dr. Janaka Ruwanpura , Dr. George Jergeas, and Mohamed Moussa  who have written (amongst other things) some great material on decision tree simulation and civil engineering PM best practices. So, while I do not expect to win, being selected as a finalist is a great endorsement and encouraging that a PMI body recognizes agile and leadership based material.

This is an emerging trend, three or four years ago agile awareness and acceptance within traditional project management was the anomaly, now it appears the norm. When I spoke at the PMI Global Congress in Anaheim in 2004 I had the only agile session there, at this year’s conference in Atlanta there will be six others with me. The reasons are clear, many companies are achieving success with agile methods and many others want to mirror them. The high change world of today’s software endeavours are “not your father’s projects” and so we need “not your father’s project management” to lead them.

The winner of the literary award will be announced next Tuesday; I’ll post the result here.

All projects face problems, but fortunately your team members have the best solutions.

Projects rarely go exactly to plan; they have a nasty habit of uncovering gnarly problems that were not anticipated, but need to be solved. This is illustrated nicely by Doug DeCarlo in his book Extreme Project Management.

The top black line depicts the planned approach moving in orderly fashion from start to finish. The lower blue line depicts how projects really progress with side tracks and setbacks as obstacles are encountered and overcome.

Yet, in attempting to solve these problems project managers too often overlook the best source of solutions, the project team. In this post I will outline why the team has the best practical solutions even when they may not be the best theoretical solutions. An example will probably help about now.

While managing a government project during an IT vendor change, we needed to quickly build rapport with the business users of the system and subject matter experts (SME) in order to maintain the development pace from the previous team. The problem faced was how do we get to know the business folks better and connect the team members and SME’s . Rather than contriving some project social event and trying to get buy-in from the business and team I presented the problem to the team in a planning meeting.

After some back and forth a team member suggested, that since quite a few of the business people went 10-pin bowling, then perhaps we should arrange a bowling social event. Others concurred, ideas for mixing the teams up (not us vs. them) were brainstormed and we ran the event. It went really well and led to other activities all of which greatly contributed to a strong relationship and a successful project.

As the PM I could have instead consulted the PMO, HR, or social psychology experts to determine the optimal team building event, but then I would have had to have sold it to the team. Here lies the first power of team solving:

Team Solving Power #1: By asking the team for a solution we inherit consensus for the proposal

So, what does the PM do on agile projects? If the team self organizes and selects their own work from the prioritized feature list, should the PM just buy pizza and keep out of the way? Well they are short changing the team if that is all they do. Rather than a fear of role erosion, PM’s should be maximizing business value delivery and looking to broaden their skill set with more leadership practices.  This post outlines four core roles and ten core principles managers of agile projects should practise. 

Working in Parallel
Before we start, the transition to agile does not happen overnight. There will be a long and sometimes awkward transition period as all the project stakeholders adopt a more collaborative and empowered approach to work. Some people will be quicker than others to make the transition and the PM often has to continue with traditional PM activities, behind the scenes, to ensure no balls are dropped on the project.

Ideas not new to agile, just a renewed emphasis
The Agile PM traits of a downward serving model and Leadership rather than Management were not invented by Agile guru’s. Instead agile teams found that the management styles that favoured people over process, collaboration over command-and-control worked best on agile projects. Leadership that moves the emphasis from doing-things-right to doing-the-right-things is a better complement to agile methods than the detail oriented task management popularized by modern project management. Interestingly, project management (emphasising achieving things through task control) is a relatively new phenomenon based on Fredrick Taylor’s Transformation View of task decomposition (1900). Whereas Leadership (emphasising achieving things through collaboration and shared vision) is as old as human collaboration itself. "When the best leader's work is done, the people say, We did it ourselves." - Lao-Tzu (604 BC)

Agile PM Role 1: Obstacle Removal

(Chop those large projects down to size)

When I started out as a PM and had a few successful projects under my belt, I wanted to manage larger and larger projects. Now I’m looking for ways to make them smaller and limit the functionality initially tackled. This is not just laziness or a lack of ambition on my behalf, instead it is a realization that delivering business value comes from successful projects and that large projects are inherently risky and more likely to fail.

Jim Johnson of the Standish Group presented some interesting metrics at the PMI Global Congress conference in Toronto a couple of years ago that confirmed my suspicion. From a study of over 23,000 projects it was found that the success rate dropped as project duration increased.

From the graph we can see that most (over 50%) of the 6 month projects surveyed were deemed successful, dropping to 23% of 12 month projects, and less than 10% of 24 month projects. Now, we need to understand what “Sucess”  means here. The criteria was quite strict and defined as within 15% of cost and schedule and to customer defined functionality and quality standards.

I expect a large proportion of these “failed” projects merely missed the 15% cost or time criteria and the picture would not be so bad with a wider margin. Predicting costs over long periods is notoriously difficult as even labour rates and inflation predictions elude the best market ecconomists. However the trend is still true, larger projects carry a much higher probability of failure for a number of reasons we will see...

Traditional project contracts are not very agile, yet we often find contracts are a part of the not so ideal real world. While the 3rd line of the agile manifesto states “Customer collaboration over contract negotiation” it is sometimes difficult to convince all the external stakeholders and powers-that-be of this wisdom.

The next Calgary ALPN meeting on Monday will feature Gerard Meszaros from ClearStream Consulting talking on “Are Fixed Price and Agile Mutually Exclusive?” This should be a good talk, I have known Gerard for 4-5 years and he always has a compelling message; backed up by a wealth of experience and a deep knowledge of agile methods. If you are in the Calgary region on Monday lunchtime, come along and hear Gerard’s presentation.

The DSDM Consortium developed a sample agile contract a number of years ago. It is based on the idea of switching from a traditional waterfall approach (fixed cost and variable time and functionality) to an agile timeboxed approach that fixes time and cost and then varies functionality.

The contract has wording that seeks business consensus of delivered value rather than conformance to a spec (that is likely wrong). The document is a few years old now and based on UK contract law not US contract law, but is definitely valuable if you are struggling with creation of an agile contract.

Download dsdm_agile_contract.doc

However, I would caution that creating an agile contract is probably the last thing you want to do and should only be considered when collaboration options have been exhausted.