Monday

Monthly Archives: April 2009

What is a project??????

Posted on April 30, 2009 by | 6 comments

The current definitions of a project have a common theme, but generally fail to differentiate projects from on-going operations. With governments world-wide starting to legislate about ‘projects’ we need to tighten up these definitions from within our profession before lawyers do the job for us!

There seems to be two elements of a project that clearly separate the practice and profession from operational work. These are:

  • Projects are about creating change. Turning a block of land into a building, developing a new business process, or writing a software program. At the end of the project there’s something significantly different in the world.
  • Projects are also temporary organisations. The key role of a project manager is to develop the temporary team, lead them in the work of the project and then dissipate the team at the end as the output from the project is transitioned to the client or operational users.

If these two factors are present, the endeavour is almost certainly a project. If one is present, it may be a project.

How do these ideas compare to the current definition of a project? The PMBOK® Guide has the following key elements in its definition:

  • It is a temporary endeavour*. Whilst this is true of a project, all endeavours are temporary. Endeavour is synonymous with ‘work’ and all work is temporary. The work by the accounts department to process the end of month accounts in a business is temporary but highly unlikely to be a project.
  • To create a unique product, service or result. Again whilst this is true, virtually every product, service or result is ‘unique’. Every Ford motorcar rolling off a production line is unique; it has a unique chassis number, a unique engine number, and has been made at a different time to the cars before it and after it. The difference between a project and an operational production item is the project is intended to create a distinct change. Producing a routine set of monthly accounts or another car from a production line is business as usual – the operation’s management may be looking for incremental improvements in their process but not change. The result of a project is a change in the environment (eg, a new building) or a change in the way the organisation works.

Other standards add additional factors to the PMBOK’s starting point such as the need for coordinated activities over time (dates), the use of resources and the presence of risk. None of these additional factors differentiate a project from operational work; all endeavours involve coordinating the activities of resources over time to achieve the intended outcome, and the outcome is always at risk.

The change needed to existing definitions of a project to actively differentiate projects from operational work is not great. The PMBOK definition could be amended from:

A temporary endeavor to create a unique product, service or result.

to:

An endeavor, undertaken by a temporary team to create a new or changed, product, service or result.

This definition may not be perfect but it’s a lot closer to differentiating projects from operational work. 

Your comments will be appreciated.

*Definitions of endeavour (various sources)=
 – a purposeful or industrious undertaking
 – an earnest and conscientious activity intended to do or accomplish something
 – an effort to do something
 – an attempt by employing effort

6 Comments

Posted in General Project Management, Project Typology

Tagged , , ,

The Right Way, the Wrong Way and the PMI Way

Posted on April 25, 2009 by | 2 comments

We are in the middle of a busy training period leading up to the change in the PMP exam. Several candidates have commented on needing to learn the PMI way rather than the real world way for their exam.

The idea that the PMI way is not real world is a very wrong assumption!

There are several factors that may make the PMI way different to your way but they are based on sound concepts. Some of the factors that create a difference are:

  • The PMBOK® Guide is a knowledge framework that contains processes that are generally applicable to most projects, most of the time. The consequence of this is the processes need tailoring for specific projects. The PMP and CAPM exams are generic and world wide they focus on answers that are likely to be correct for most people most of the time.
  • The PMBOK is developed by hundreds of project managers from around the world. The result is a coordinated amalgam of ideas. The PMP exam is based on the information in the PMBOK and information drawn from a range of text books written by leading authors. All of the correct answers are based on information from people with significant project management know-how. This may be different to yours but it is valid.
  • PMI has aspirations for the profession of project management. Some underlying themes found in the majority of questions such as the high level of proficiency of the performing organisation and the professional competence of the project managers may be a stretch based on the culture of your organisation but are highly desirable aims and are not unrealistic.

Building a major oil platform in the North Sea is different to writing a small software patch in Bangalore (and both are projects) so the exams will always contain elements that are not right for your projects.

This does not devalue the way you do your projects. As long as the projects your organisation manages are constantly delivered on time, on budget, on scope and fully satisfying all of the key stakeholders. If this happens,  your organisations approach to project management is obviously right in the context you are working in. It is just your way is different to the generally accepted way most successful projects are delivered world-wide and the PMI exams are focused on this generally accepted view of good practice.

2 Comments

Posted in Training

Tagged , , , , , , , ,

PMI Exam Changes PMP and CAPM

Posted on April 25, 2009 by | 1 comment

Exam candidates need to know the change dates of 1st July for PMP and 1st August for CAPM are absolute! All examination deferrals and re-sits taken on or after these dates will be based on the new exam.

This policy will involve some extra work for PMP candidates and a complete re-run of your training for CAPM candidates if your training has been based on the current PMBOK® Guide 3rd Edition. The scope of changes between the 3rd and 4th Editions is very significant at the detailed level needed for the examinations (particularly CAPM).

You’ve been warned!!

1 Comment

Posted in Training

Tagged , , , , , , , ,

PMI’s ‘Voices on Project Management’ Blog

Posted on April 19, 2009 by | 3 comments

Just a quick note to let you know I have joined the PMI ‘Voices on Project Management’ team of bloggers. Over 40 people commented my recent post discussing the Agile software development methodology [see my posts].

Given PMI’s central role as a project managment standards developer, you are all encouraged to join in the discussions sparked PMI’s range of ‘voices’ on their blogs to help drive the evolution of project management world-wide.

3 Comments

Posted in Agile Ideas

Tagged , , ,

Ask for information you can use

Posted on April 16, 2009 by | 1 comment

Folowing on from my earlier post ‘A though on PMOs and Project Controls’ , PMOs and projects regularly collect and report on data but you have to ask how often is the data converted into information the organisation can use?

I have just wasted 15 minutes trying to respond to a survey commissioned by our local city council. The structure of the survey was so bad there is no way the data collected would allow any useful information to be gathered. Two of the questions (from memory) were:

  • ‘Overall how do you rate the Port Phillip City Council’s performance’ with a range of 5 options from bad to excellent. Sound like an insightful question but what does the answer tell anyone?? The Council delivers a wide range of totally separate services from refuse collection to maternal and child welfare. Any overall answer is meaningless; unless the Councillors are spending rate payer’s money on a ‘feel good’ ego trip and hope they will be rated ‘good’. It does not matter if the answer is bad, good or indifferent unless the data collected identifies what is good or bad so management action can be taken to lock in the good and improve the bad.
  • “How do you rate the street cleaning service overall?”  More specific but still useless data. The council cleans shopping strips on a daily basis, other roads on an occasional basis and numerous lanes and footpaths very rarely. My answer was shopping strips great, major roads OK, side roads like the one I live in fairly poor and the laneways are a total disaster….. But how would I rate the service overall??? At this point I terminated the interview!

    Overall rating should be complied from specific measurements weighted appropriately. In this case a weighted assessment of the relative importance of clean shopping strips -v- clean local streets -v- clean laneways to the local citizens. How do you assess the weightings? Ask a sample group of people which they feel is more important on a comparative basis before running the survey. Then collect specific data and build some useful information that can help direct improvements in the overall service.

When designing this sort of data gathering, you also need to filter out influences like staff culture (the Port Phillip staff are really great and helpful) from systemic issues such as the contract conditions the street cleaning contractor operates under.

Then by compiling all of the various rating for the specific services, an overall rating for the council could be compiled and more importantly the high performing areas noted and lessons from these areas transferred to the less well performing areas.

There’s a lot to learn from this example of bad surveying. Designing surveys and collecting data is not a trivial exercise. There is nothing simpler than bogging a PMO down collecting masses of data that can never be converted into useful information. Do this and the PMO will be seen as a useless bureaucracy and sooner or later it will be reorganised out of existence.

Focus the data collection on a limited range of key factors that can provide useful management information and the PMO will be seen as a real value add to the business.

So how do you rate your PMO overall?     Only kidding…..

On a closing note –
The number of really bad surveys seem to be increasing exponentially – I think around 80% of the various project management surveys I look at, mostly from post graduate students, seem to be either designed to support a pre-determined answer or so badly designed the data could be interpreted to suit any answer the researcher chooses. There is a real discipline and skill in developing an effective survey; unfortunately it’s a skill that seems to be in very short supply.

1 Comment

Posted in PMOs

Tagged , , , , , ,

Frank Costigan QC

Posted on April 14, 2009 by | Leave a comment

This is a brief post to mark the passing of a truly inspirational lawyer. I have been privileged to meet Frank Costigan on a number of occasions a various functions for Arbitrators arranged by the Institute of Arbitrators and Mediators, Australia (IAMA).

Despite his courage and fame associated with tackling organised crime in Australia during the 1980s (The Costigan Royal Commission), I met a gentle, caring and gracious human being.

Franks credo is well worth reflecting upon:

“ … No man is an island, entire of itself; every man is a piece of the Continent, a part of the main; … any man’s death diminishes me, because I am involved in Mankind, and therefore never send to know for whom the bell tolls; it tolls for thee …” – John Donne
“Meditation XVII: Nunc Lento Sonitu Dicunt, Morieris”

If the mark of greatness is making a difference in this world, Frank Costigan QC certainly achieved greatness.

Leave a comment

Posted in Thoughts & Musings

Tagged , ,

PMBOK -v- Methodology

Posted on April 11, 2009 by | 9 comments

Earlier this week, I was reviewing proposed abstracts for the PMOZ project management conference in Australia. One paper proposed comparing the PRINCE2 Methodology with the PMBOK Methodology.

The paper did not get accepted because its basic premise is completely wrong! The PMBOK® Guide is not and never has been a methodology.

Methodologies define the processes, responsibilities and workflows needed to achieve an objective. PRINCE2 is a good project methodology for managing projects with a large internal component. Agile and Waterfall are two different software development methodologies that incorporate elements of project management.

The PMBOK® Guide is an international standard. To give it its full name, it is A Guide to the Project Management Body of Knowledge. The processes described in the PMBOK® Guide are generally accepted good practice that apply to most project most of the time. This is the foundation for a good project management methodology but the PMBOK® Guide is not, and cannot ever be a methodology without adaptation.

The step between the PMBOK® Guide and a methodology is determining what, who and how:

  • What of the processes should be applied in you organisation, to what extent and with how much rigour?
  • Who is responsible for the implementation of the processes, including; generic roles and responsibilities, project org. structures and governance committees
  • How the processes will be applied, templates, guidelines and workflows.

These are critically important issues.

  • If a PMO sets out to ‘implement the PMBOK’ you are heading for disaster.
  • If the same PMO sets out to develop a tailored methodology based on the good practices described in the PMBOK you are potentially on the right road.

Certainly in my business, if someone does not know the difference between a standard and a methodology, I tend to start asking a lot more questions about their competence. Having been involved in the last two upgrades of the PMBOK® Guide I consider it to be a very valuable resource to underpin the development of any project management methodology but you still need to do the hard work of determining the what, who, how and ‘how much’ for yourself to build the methodology and optimise the outcomes for your organisation.

Happy Easter.

9 Comments

Posted in General Project Management

Tagged , , , , , ,

Projects aren’t projects – Typology

Posted on April 9, 2009 by | 7 comments

Following on from my first post on ‘projects aren’t projects‘; one of the more established ways of describing projects is a typology that maps the interaction of uncertainty and technical difficulty. Knowing both ‘what to do’ and ‘how to do it’; or more importantly knowing how much you know about these two elements. The typology was developed by Eddie Obeng in the Project Leader’s Secret Handbook.

Project Typology

The typology asks two questions:

  • Are you clear about what to do (the outcome to be achieved)?
  • Do you know how to do it (processes, methods, experience)?

Painting by Numbers
Traditional project management works well when both ‘what’s to be done’ and ‘how to do it’ are well understood by all key stakeholders including the client and the project team. Closed projects (panting by numbers) can be fully defined, estimated, planned, etc. There are low levels of uncertainty and ambiguity, risks are largely known and manageable. Value is largely achieved by delivering the requirements on time and on budget.

A typical software project of this type would be installing a software upgrade into an office where the same upgrade had been previously installed in several other locations.

Going on a Quest
In these projects, the objective is clear but the way to achieve the objective is uncertain. At the end of the day, success or failure is clear cut; the objective has been achieved (or not). The challenge is optimizing the way forward. Process and system improvement projects tend to fall into this category. The objective is to reduce processing time by 20% – this is easily measured on the completion of the project. The difficulty is knowing what’s the best way to achieve the objective. Improving the user interface, simplifying the work flow, speeding up network traffic and processing times or a combination? Ambiguity is low – we know what’s needed, uncertainty is high – we are not sure how to achieve it.

Before committing major resources to the main work of the project adequate time has to be allowed to prototype solutions and test options before a final design solution can be determined and then implemented. The project needs to be developed in phases with go/no go gateways as the design is firmed up. There are risks associated with any creative design process and most software projects are ‘quests’ requiring creative solutions to identified problems to achieve the desired objective.

Making a Movie
In these projects the tools and techniques are well known but the final outcome is uncertain. Only after the project is complete can the results be measured and the success or failure of the project determined. Most culture change projects and marketing projects (and making movies) are in this category. The tools to be used including: training, communicating, advertising, etc are well known and the traditional (if not optimal) mix of techniques understood for most situations. What no one can predict is if the ‘public’ will acclaim the final result, merely accept the final result or dump the final result.

Traditional project management is not enough in these projects; there is a continual need to measure results, feedback information and adapt the mix of activities to optimize the likelihood of success. The key value measurement is attempting to answer the question is it worth spending more or should we cut and run? Efficient stakeholder communication and relationship management is crucial. Whilst there will be some outstanding successes (block busters) and some total flops most projects in this category finish somewhere in the middle. The art is spending just enough effort to achieve an acceptable outcome – dealing with shades of grey.

Lost in the Fog
I actually prefer Prof. Rodney Turner’s version ‘a walk in the fog’. This project is a journey towards a desired new state. No one is sure of the optimum outcome, or how best to achieve it. The only option is to proceed carefully, stop at regular intervals to check exactly where you are and re-plan the way forward. Exactly the way you navigate through a thick fog. Both ambiguity and uncertainty are high.

Project management is about making sure at each ‘stop point’ the value achieved to date is locked in and then refocus on the next increment. Agile software development is ideal for this type of project. Each iteration builds new capability and value and the learning provides a platform for the next iteration of development.

Management is both easy and difficult. It is easy because there is no point in setting fixed plans (you have no idea what to plan). It is difficult because decisions on value and whether to stop or continue are subjective and need to be made in a collaborative environment of trust. Traditional measures of success such as on-time and on-budget are largely meaningless; typically there are no statistics to base this type of measure on. Consequently these projects are the realm of cost reimbursable contracts and partnerships; stakeholder relationship management, and a clear understanding of value are the only effective tools for building to a successful outcome.

Two final thoughts
The skills required of a project manager change from largely technical if the project is ‘painting by numbers’ to almost completely relational to manage a ‘walk in the fog’. For more on this see: Tapping the Power Lines and The Accidental Project Manager – The Getting of Wisdom

Both the client/sponsor and the project team need an understanding of the type of project and agree to configure the project management processes appropriately. The more uncertainty and ambiguity, the more important the project  client is to achieving project success!

More later.

7 Comments

Posted in Project Typology

Tagged , , , , , ,

PDUs and the PMI Examination Eligibility Requirements

Posted on April 9, 2009 by | 5 comments

Eligible Training hours

There’s a lot of confusion about the role of PDUs and the PMI exam eligibility requirements. The simple fact is PDUs are different to the hours of approved education needed to be eligible to sit for a PMI credential.

Approved education hours are accumulated by completing courses focused on the knowledge framework for the examination (basically the 9 knowledge areas of the PMBOK Guide for CAPM and PMP).  PMI requires the following:

  • CAPM 23 Hrs of approved general project management education
  • PMP 35 Hrs of approved general project management education
  • PMI-SP 40 Hrs of approved education in the specialist area of project scheduling
  • PgMP has no formal education requirements.

In the event of being audited, to prove to PMI your training is eligible you either need

  • a certificate from a PMI approved Registered Education Provider (R.E.P.) such as Mosaic
  • or the course transcript showing the course covered the knowledge framework defined in the exam specification.

Eligible training hours are very specific, you can earn them by attending a classroom based course or participating in a web or email based course – it’s the course content that matters.  Eligible training does not have to be an exam preparation course, any combination of courses that cover the required knowledge framework count!

However, there is a significant difference between ‘eligible training’ and ‘effective training’.  Eligible training will allow you to apply for the examination.  To be reasonably sure of passing your examination specific preparation is essential (all PMI examinations have a fairly high failure rate). The purpose of a well structured exam prep course is to align your knowledge with the specific requirements of PMI’s mult-choice exam questions. For more on this see The Right Way, the Wrong Way and the PMI Way.

PDUs

PDUs are completely different – the requirements for PDUs are set out in the PMI Continuing Certification Requirements handbook (CCR). PDU stands for Professional Development Unit.

As a starting point, you can only earn PDUs after you have passed your exam. Exam preparation courses cannot provide PDUs for the credential you are studying towards: you have to complete the course to be eligible to sit the exam and can only earn PDUs after you have passed the exam.

In limited circumstances the study for another credential may earn PDUs; if a person already holds a PMP credential and is undertaking a course of study for the PMI-SP credential, the hours of training for the PMI-SP would earn PDUs for her PMP but NOT for her PMI-SP.

The only way for a PMP to earn PDUs from a PMP exam prep course is to take a second PMP exam prep course after you have passed your PMP. As a training organisation we can see some merit in this ($$$$) but practically there is no point.

The other key difference is PDUs can be earned from a very wide range of activities including attending conferences, participating in webinars, being a volunteer and writing papers as well as attending training courses. Similarly for a training course to earn PDUs it only has to be relevant to your work and associated with project management (eg, an ITIL course). This covers a very much wider spectrum than the focussed training needed to to earn the hours needed to be eligible for a credential.

Click here for more on earning and recording PDUs

Summary

  • Most activities that improve your capability as a professional will earn PDUs.
  • Only focused training based on the exam specification counts towards the training hours needed to be eligible for a credential.
  • You must accrue the eligible training before applying for the credential
  • You can only start earning PDUs after you have passed the credential.

For more information see:

5 Comments

Posted in Training

Tagged , , , , , , , , , , , ,

Projects aren’t Projects

Posted on April 7, 2009 by | 2 comments

Project management is not a one-size-fits-all process or discipline. The PMBOK® Guide makes this clear in Chapter 1. There are at least 4 dimensions of a project,

  • its inherent size usually measured in terms of value;
  • the degree of technical difficulty (complication) involved in the work;
  • the degree of uncertainty involved in defining its objectives; and
  • the complexity of the relationships surrounding the project.

Project Size
The size of the project will impact the degree of difficulty in achieving its objectives but large projects are not necessarily technically complicated or complex. There are projects in Australia to shift millions of cubic meters of overburden from mine sites with expenditures rising to several $million per day but the work is inherently simple (excavating, trucking and dumping dirt), and the relationships in and around the project are relatively straight forward. The management challenges are essentially in the area of logistics.

Technical Difficulty (degree of complication)
Complicated high tech projects are inherently more difficult to manage than simple projects. The nature of the technical difficulties and the degree of certainty largely depend on how well understood the work is. The important thing to remember with complicated work though is that systems can be developed and people trained to manage the complications. The work may require highly skilled people and sophisticated processes but it is understandable and solvable.

Uncertainty
The degree of uncertainty associated with the desired output from the team’s endeavours has a major impact on the management of the project. The less certain the client is of its requirements, the greater the uncertainty associated with delivering a successful project and the greater the effort required from the project team to work with the client to evolve a clear understanding of what’s required for success. This is not an issue as long as all of the project stakeholders appreciate they are on a journey to initially determine what success looks like, and then deliver the required outputs. Budgets and timeframes are expected to change to achieve the optimum benefits for the client; and the project is set up with an appropriately high level of contingencies to deal with the uncertainty. Problems occur if the expectations around the project are couched in terms of achieving an ‘on time, on budget’ delivery when the output is not defined and the expected benefits are unclear. Managing uncertainty is closely associated with and influences the complexity of the relationships discussed below.

Complexity = The People
Complexity Theory has become a broad platform for the investigation of complex interdisciplinary situations and helps understand the social behaviours of teams and the networks of people involved in and around a project. These ideas apply equally to small in-house projects as to large complicated programs. In this regard, complexity is not a synonym for complicated or large. It focuses on the inherent unpredictability of people’s actions and reactions to ideas and information within the network of relationships that form in and around the project team.

Discussion
Size is straightforward and most organisations have processes for assigning more experienced project managers to larger projects. What’s missing is consideration of the other three aspects.

The last item, complexity is very much an emerging area of thought and discussion. For a brief overview see: A Simple View of ‘Complexity’ in Project Management  and for some practical considerations of the impact of complexity theory on scheduling see: Scheduling in the Age of Complexity. However, I expect it will be some years before ‘complexity theory’ and project management sit comfortably together.

Of more immediate interest is the interaction of uncertainty and technical difficulty. Knowing both ‘what to do’ and ‘how to do it’; or more importantly knowing how much you know about these two elements is critically important in establishing a framework to manage a project. Some ideas on this topic will be the subject of my next post.

2 Comments

Posted in Complexity, Project Typology

Tagged , , , , , , ,