Monthly Archives: September 2009

Project Management 2.0

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Tradtional PM

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

  • Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
  • All good project management is based on collaboration.
  • All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
  • Access to information is vial when and where needed.
  • Open and effective communication is critical.
  • Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
  • Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

  1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
  2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

Stakeholder Management with apologies to Dr. Seuss

When beetles battle beetles in a puddle paddle battle and the beetle battle puddle is a puddle in a bottle…
…they call this a tweetle beetle bottle puddle paddle battle muddle.
Excerpted from: Tweetle Beetles, ‘The Fox in Socks’, by Dr Seuss

The connection between a book written to be read to under 5s and business stakeholder management is the ‘puddle muddle’ otherwise known as the stakeholder pool. The challenge of managing stakeholders is a factor of the disturbance caused by dozens if not hundreds of battles most of which, the person attempting to efficiently manage his or her stakeholders has no control over whatsoever.

Most stakeholder management methodologies start by assessing the stakeholder from the perspective of the work. This is not unreasonable but can easily miss many important factors.

The Stakeholder Pool

Figure 1: The Stakeholder Pool

Figure 1 shows ‘the stakeholder’ in the overall stakeholder pool being influenced by the ripples created by your battle in your part of the pool (your puddle). Unfortunately the stakeholder pool is a much bigger, more turbulent place.

Figure 2: the Stakeholder Pool with turbulance

Figure 2: the Stakeholder Pool with turbulence

Show some of the other disturbances in the pool and you start to see the stakeholder buffeted by waves and impacts from all directions, in Figure 2. ‘The stakeholder’ is continually being buffeted by waves from other projects, the organisation and many other influences. These other waves are one of the prime reasons stakeholder responses to your perfectly reasonable needs or suggestions are frequently so unpredictable. All of these influences, both current and past have helped shape the stakeholders perceptions and attitudes towards your industry, your organisation and ultimately, you.

Consequently, a single view point is really not sufficient! Effective stakeholder management needs an organisational approach. Successful stakeholder management requires all of the influences perceived by the stakeholder to be coordinated and authentic. And this can only be achieved by the organisation as a whole adopting mature, ethical stakeholder management as a core discipline.

Very little has been written about mature organisational stakeholder management until recently. To date, the focus of most papers have been one dimensional focusing on CRM and the ‘customer experience’ or one dimensional focusing on the relationship between the stakeholder and a project (or other organisational activity).

A new book, Stakeholder Relationship Management: A Maturity Model for Organisational Implementation, by Dr. Lynda Bourne takes this next step to define the interaction between the organisation as a whole and its stakeholders using the Stakeholder Relationship Management Maturity (SRMM®) model.

Effective and ethical stakeholder management cannot happen overnight and cannot happen in isolation. The preconceived perceptions of stakeholders towards your work are based on multiple experiences over an extended period of time, and the stakeholder-to-stakeholder conversations that occur outside of your hearing or control. To actively improve these conversations and create a positive and supportive stakeholder environment needs a long term consistent effort, organisation wide.

Bourne’s SRMM model offers a practical framework that can be used by organisations to build from ad hoc, single project attempts to manage stakeholders to a situation where stakeholder management is a core skill used by the organisation as a whole to maintain a competitive advantage. As with any culture change, this cannot happen overnight but at least Dr. Bourne’s new book provides a road map organisations can use to improve their management of stakeholder relationships to the benefit of both the stakeholders and the organisation.

Stakeholder Relationship Management: A Maturity Model for Organisational Implementation is published by Gower, ISBN: 978-0-566-08864-3

Thoughts on Agile

Following on from a rather lengthy on-line discussion covering various aspects of the interface between the Agile software development methodologies and project management, we have developed a discussion paper that looks at how the two processes can be integrated.

The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated.

The paper can be downloaded from:

Free PMP Questions

The quality of many comments and resource available on the web for the PMP exam are doubtful to say the least.

Apart from issues with various PMP guarantees discussed in an earlier post (view: Guaranteed PMP Pass?), my major bugbear is the array of half-baked PMP questions available. I am sure the high PMP fail rate is partly due to people having a false sense of security based on ‘successfully’ answering a range of simple free questions…….

To help counter this we have developed a set of 30 questions as a free resource (no log-on required) focused on real PMP level knowledge assessments. If you, or anyone you know wants to see how their knowledge stack up you are welcome to have a go….. The questions are available from

Whilst the problems with CAPM are less, we have also developed 25 CAPM questions which are available from

Apart from normal web traffic monitoring there are no systems on these pages to track users or downloads and being we are a small business based in Melbourne Australia there’s little ‘commercial’ value to us in people making use of the free facility outside of our home base, so please feel free to pass this resource on to anyone you know interested in the PMP exam (having done the hard work writing the questions I would hate to see it wasted).

Resourcing Schedules – A Conundrum 2

Following on from comments to my post ‘Resourcing Schedules – A Conundrum’  there are still some basic problems to resolve.

As the commentators suggest, KISS is certainly an important aspect of effective resource planning: ie, planning resources at an appropriate level of detail for real management needs. But the basic issues remain; you cannot rely on a scheduling tool to optimise the duration of a resource levelled schedule.

We use the basic network below in our Scheduling courses (download the network – or – see more on our scheduling training)

Network for Analysis (download a PDF from the link above)

Network for Analysis (download a PDF from the link above)

No software I know of gets this one ‘right’.

When you play with the schedule, the answer to achieving the shortest overall duration is starting the critical resource (Resource 3) as soon as possible.

To achieve this Resource 2 has to focus 100% on completing Task B as quickly as possible BUT, Task C is on the Time Analysis critical path not Task B and 99% of the time software picks C to start before B.

This is not a new problem, a current paper by Kastor and Sirakoulis International Journal of Project Management, Vol 27, Issue 5 (July) p493 has the results of a series of tests – Primavera P6 achieved a duration of 709, Microsoft Project 744 and Open Workbench 863. Play with the resource leveling settings in P6 and its results are 709, 744, 823, 893 – a huge range of variation and the best option (P6) was still some 46% longer than the time analysis result . Other analysis reported in the 1970s and 80s showed similar variability of outcomes.

As Prof. George Box stated – All models are wrong, some are useful… the important question is how wrong does the model have to be before it is no longer be useful.

Computer driven resource schedules are never optimum, done well they are close enough to be useful (but this needs a good operator + a good tool). And good scheduling practice requires knowing when near enough is good enough so that you can use the insights and knowledge gained to get on with running the project. Remembering even the most perfectly balanced resource schedule will fall out of balance at the first update…..

How you encapsulate this in a guide to good scheduling practice is altogether a different question. I would certainly appreciate any additional feedback.

Guaranteed PMP Pass?

Prospective candidates for any PMI examination, including the PMP credential need to be vary wary of ‘guarantees’ from some training organisations.

PMI closely manage the security of their exam system and no one can ‘guarantee’ a pass. Candidates take a secure exam with an individually selected mix of questions and pass if they score more than 61% on the day. Less than 61% correct answers = failure!

Despite PMI explicitly prohibiting R.E.P.s from offering guarantees that cannot be substantiated, and obviously ‘guaranteeing’ a pass is impossible, it does not stop some organisations:

Guarantees that you will ‘pass the exam’ are fraudulent – deal with businesses making this type of impossible guarantee at you peril.

Guarantees to refund some or all of your monies in the unfortunate event of a failure are permitted under PMI’s advertising policies but PMI require the conditions of the guarantee to be clearly stated.  Some of the primary problems with ‘guarantees’ are:

  1. Unrealistic time limits, eg requiring you take the exam within seven (7) days of completing the course – this is impossible if you have not already completed 35 Hrs of training and are pre-registered with PMI.  The PMI booking cycle takes on average 8 to 10 days.
  2. The number of time you have to fail the exam before the ‘guarantee’ is effective – most guarantees require at least one re-sit, many two (ie, the maximum allowed by PMI). These are usually time limited to 30 days per re-sit.
  3. The amount of work you have to do before the ‘guarantee’ is effective?
  4. The actual value of  the ‘guarantee’  – you will have spent money on course fees, exam fees, re-sit fees, travel and time out of work for the exams and a significant amount of study time.

If the conditions are clearly defined and you feel they offer value to you, obviously accept the guarantee.  If the guarantee conditions are hidden in a mass of fine print you can judge the ethical base of the organisation making the guarantee for yourself.

Mosaic is a PMI R.E.P. However, we operate from a very different ethical basis:

  1. We guarantee to keep working with trainees until they pass (ie, we spend our time and money working with the one or two people unlucky enough to fail each year until they either pass or decide to move on).
  2. We do not offer a money back guarantee (with or without multiple hoops for the trainee to jump through) for two reasons:
    1. We feel it important for trainees to have some ‘skin in the game’.
    2. We don’t think it is reasonable to charge a premium on all candidates’ fees to cover the risk for a few.

The challenge I propose to all prospective PMP candidates is to check out the actual guarantees from potential training providers and ask yourselves two questions:

Do I want to deal with an organisation that offers sham guarantees – what does this say about other aspects of their business ethics and service?

Do I want to pay the price premium associated with many ethical guarantees? 
PMI Melbourne Chapter offer PMP classroom courses for $1,980.00 for PMI members
Mosaic offers email based training for $1,320.00
(see: both courses have a 98%+ pass rate.

I my opinion, there’s nothing wrong with ‘money back’ guarantees provided the terms are clear and not too onerous, many reputable R.E.P.s offer this type of guarantee. However, for other ‘impossible guarantees’, PMI have been working to clean up the advertising of PMP courses by R.E.P.s for several years you can help by voting with your feet and not doing business with organisations that offer impossible guarantees. 

Resourcing Schedules – A Conundrum

I have recently been forced to think about the value of incorporating resources into schedules. At one level it’s not too hard to do, but is it useful?

From one aspect, it is impossible to schedule at any level without the active consideration of resources. Resources do the work in a given time and changing either the quality or quantity of the resource has some inevitable impact on duration. Consequently, it is critical to know the resource assumptions used in planning to validate the schedule and more importantly understand deviations from the plan during the execution of the work.

Generally what I mean by term ‘considered’ is the basic need to know the resources needed to undertake the work on every activity:

  • At the feasibility stage big picture tied to the strategy for the project.
  • At the contract stage to determine which tasks are the responsibilities of what contractor/subcontractor.
  • At the weekly level, the supervisors need to know who is working where and when.

These decisions also need to be recorded and monitored. How much detail is recorded in the scheduling tool and what scheduling functions are used though is an altogether different question – this I refer to as ‘quantitative’ resource analysis.

Consideration is not the same as quantitative analysis within a scheduling tool. Quantitative resource analysis requires answers, or assumptions to be made, about a range of uncertain issues. Some of the nearly insoluble questions include:

  1. There is no direct ‘straight line’ correlation between resource quantities and either task or project durations – there is a complex ‘J’ curve relationship and in some circumstances a negative correlation. For more on this see: The Cost of Time or for a more learned approach, The Mythical Man Month by Frederick P. Brooks Jr. originally published in 1975.
  2. It is nearly impossible to define skill levels for people who will be employed on a project at some time in the future but we know a skilled worker can be far more productive than an unskilled worker. The skill of the worker changes the production rates and consequently the durations.
  3. The other issue is the degree of motivation/moral of the people – a highly motivated team will always accomplish more than a ‘business as usual’ team and both more than a de-motivated workforce. Therefore the question of management and more importantly leadership also influence resource performance and therefore durations.

These unanswerable questions are complicated by the fact all scheduling software fails to optimally level resources . Basically the tools get it wrong the only question is how wrong: some are not too bad others unmitigated disasters. Resource scheduling needs both knowledge and common sense – no software applies common sense yet. But we have to plan resources – they need working space, accommodation, etc. And resources are the source of all cost expended on the project!

Another really interesting factor is the emerging understanding of the interaction between the schedule and the behaviour of people. IF the people believe the schedule represents a realistic approach to their work, they will (and do) modify their behaviours to conform to the schedule to be seen as successful. Obviously if resources are included in the schedule it is far more credible than if they are not. This was touched on in Scheduling in the Age of Complexity (read from p19 – the rest is not relevant and it’s a horribly long paper…. with a bit of luck this may turn into a book in a couple of years….).

So in conclusion I would suggest, consideration of resources is critical, as is having some form of method statement; together they dictate the planned durations of the work.

However, whilst using scheduling tools to calculate and level resource demands is useful, and can help gain valuable insights, you need real skill on the part of the scheduler and the right tools to achieve sensible results.

My feeling is the value of the process to the development of a realistic and achievable schedule depends on the circumstances of the project. Probably the biggest determinant of the value of quantitative resource analysis is the ease of adding to or reducing the resource pool. If this is easy, rudimentary quantitative analysis is all that’s needed, if any. If it is difficult to quickly change the resource pool far more rigour is required (eg, developing remote area mine sites in Australia). The quantitative analysis will still be ‘wrong’ but it is important to reduce the level error as much as possible.

This is a complex issue – what are your thoughts?