Agile has become the Rodney Dangerfield of the project management world!

20140419-142624.jpgFollow discussions in any online PM community over a couple of weeks and you’ll run across at least one discussion thread vilifying agile project management.

Whereas a few years back supporters clearly outnumbered the naysayers, the balance appears to be shifting in the opposite direction.

This resistance might arise as a consequence of the failures a number of companies have had in successfully implementing agile methodologies coupled with the very understandable fatigue of listening to one too many fanatics preach its virtues.

However, I’m not quite ready to throw the baby out with the bath water.

Agile is just one tool in the utility belt of an experienced project manager, but like any tool, it needs to be used the right way and for the right purpose.

To that end, I’d like to debunk just a few of the more common misconceptions held by those who have either never worked on agile projects, or those who have experienced agile gone horribly wrong.

  • Agile means undisciplined: In order to deliver products or services frequently and to be able to meet customer expectations within fixed cost or schedule constraints, teams need to apply more rather than less discipline. A lack of quality in producing key deliverables impacts velocity through unnecessary rework and a good self-managing team will take swift steps to ensure such defects will not recur. Well-run retrospectives help to identify ideas for the team to implement in future iterations to be more productive – this cannot be achieved by the undisciplined. Finally, well designed architectures and risk-driven design are also hallmarks of well-run agile projects – again, not evident in undisciplined environments.
  • Agile means no documentation: Agile, like lean, attempts to eliminate waste which does not add value to the customer. While an agile project might generate less documentation than a traditionally-managed one, documentation which is essential to producing high quality deliverables will still be created.
  • Agile means no measurements: The total number of different project status elements captured might be reduced, but the remaining ones are sufficient to gauge progress. Instead of having teams subjectively assess percentage complete or work effort remaining, each sprint or iteration will end with teams identifying which work items were completed. This in turn enables regular calculation of velocity which can be used to forecast completion of work item backlogs.

Agile is not for every organization or for every project.

Specific practices can have broad applicability, but the behavioral, cultural, quality & resource changes required to successfully implement a specific agile methodology takes real commitment and follow-through.

However, the same can be said about implementing PMOs, and organizations continue to set those up, this should not be taken to mean that failure is inevitable or that agile has had its fifteen minutes of fame.

Categories: Agile, Project Management | Tags: , , , | Leave a comment

Please use PLS when managing your projects!

peer-support-group-200x200Courses on quality teach us that the cost of defect correction is much greater than the cost of prevention and that these costs are not always financial.  The cost of a software bug which is not caught prior to release extends beyond unplanned rework, release management & communication efforts to reputational impact and even potential legal action.

What does this have to do with project management?

The same rules which apply to customer-facing outputs also apply to the project manager’s deliverables produced to support the delivery of a project’s scope.  The project plan, work breakdown structure, schedule, risk register and many other artifacts all represent the hard work of many different roles, but are primarily associated with the project manager and if the quality of any of these is lacking, the project manager’s credibility will be impacted the most.

Now you might disagree with me and say that many of these deliverables have multiple cross-functional reviewers who will inspect them before they are signed off.  After all, most functional managers won’t blindly endorse a project schedule without confirming first that the proposed allocations for their staff are accurate and with such reviews the potential for meaningful impact to projects would be reduced.

While this might be true for some artifacts, it is usually not common for all key project management artifacts to receive thorough external reviews, and the “lens” which is used by the reviewers is likely focused on the impact to their own areas or work. On top of that, even if there are no tangible impacts on project success, quality issues will color perceptions of the project manager’s abilities.

So what’s the solution?

If your organization has a PMO, you might be tempted to push this responsibility on to that entity to proof all key project management deliverables prior to their release. Unfortunately, this will just create a bottleneck as it’s rare for PMOs to have surplus skilled staff available to provide such services. A PMO can help, but it would be through as-needed consultation or through random spot checks.

A better solution is to draw on a common development practice and utilize PLS – Peer-Level Support.  Having a peer inspect your work before it is released to others helps as they will be looking at it through the eyes of a project manager and are less likely to draw conclusions or judge your effectiveness than someone in a different role.

One of the best aspects of this practice is that it can start quite small with just a couple of PMs and grow incrementally.  Over time, if this practice becomes institutionalized, it will reduce the magnitude of nit-picking done during such reviews as PMs realize that “with what judgment ye judge, ye shall be judged”.

PM friends don’t let PM friends release low-quality artifacts!

Categories: Project Management | Tags: | Leave a comment

Stakeholder analysis enables effective risk management

stakesThere are an almost unlimited sources of input into the risk identification process.  Assumptions analysis, expert knowledge, constraint, dependencies, a work breakdown structure, and of course the fears, uncertainty and doubt of your team members.  With so many inputs, it can be challenging to ensure that a focused, meaningful set of risks is identified and managed.

If you come up with an exhaustive list of risks, the effort spent in managing them will likely exceed the benefits realized, and worse, by drowning your sponsor and other stakeholders in minutiae you will be reducing perceived credibility in your team and in project risk management in general.

So how can we apply an appropriate level of filtering to which risks are managed and communicated?

A good place to start is with stakeholder analysis.  By performing a preliminary stakeholder analysis, you can determine the following:

What specific concerns do they have about your project?  For example, are they more worried about its change impacts, or are they looking at it through the lens of a “bean counter”?  That will help you understand which risks are likely to be meaningful to them as well as which they would be likely to actively respond to as risk owners.

What is their risk bias? If they are highly risk tolerant, you may not get as much support from them in responding to risks as you’d like.

How actively do they wish to be involved in your project?  Highly engaged stakeholders will likely add a lot of value by participating in risk identification & assessment sessions and may actively volunteer to own certain risks whereas those who don’t see your project as being of high importance to them may not add much value by being invited to these sessions.

How optimistic are they regarding the project’s chances for success?  If you have a stakeholder who is a Sally Sunshine, she might be a great input into opportunity identification, but might be a lot less helpful in identifying threats.

Of course, one of the biggest benefits which stakeholder analysis can deliver is in helping to identify those stakeholders who are clearly not supportive of the project.  Their actions pose clear and present danger to your project’s outcomes, and while you may not reflect these risks in a publicly shared risk register, they need to be managed as effectively as the more politically correct risks.

If we accept Dr. David Hillson’s description of risk as being “uncertainty that matters“, the question should arise – matters to whom?  The answer is your key stakeholders.

 

Categories: Project Management | Tags: , , | Leave a comment

Create a free website or blog at WordPress.com. The Adventure Journal Theme.

Follow

Get every new post delivered to your Inbox.

Join 202 other followers