The triple constraints of Scope, Budget and Time is widely used in project management practices, trainings and publications. The “iron triangle” showing the 3 constraints together (with sometimes Quality or Customer satisfaction in the middle) – with the explanation that if one of the constraint is moving then the other are very likely to be impacted – became a reference in the profession.

Project manager job advertised will ask for PMs able to manage those constraints. Candidate are usually used to this as well.

But things are changing. The triple constraints has officially been enhanced in the latest version ofPMBOK (4th edition, page 6). Now the competing constraints include BUT are not limited to: scope, quality, schedule/time, budget, resources and risks. So other constraints could be considered such as customer / stakeholders satisfaction, environmental impact, etc…In other words the triangle is obsolete.

This is the acknowledgement that a project’s environment is complex and subject to many internal and external constraints, this has become visible with the expansion of virtual teams, outsourcing, off-shoring, public concerns about the environment, real-time information and all those factors that are forcing organisation to be more adaptable and more in contact with its environment. What it means for projects is that they operate with more and more constraints.

Human Resources: projects are fighting against each other for human resources shared across projects. At the same time, effort spent on project are monitored more closely and charged to the project. Project managers have therefore to consider the HR constraints with a lot more care.

Quality: with the growth of outsourcing and externalisation, more and more projects involve buyer-supplier relationship. This means that often “quality” is contractually defined, mandatory to deliver. The importance of quality has therefore increased dramatically for project managers.

Risks: sources of risks are increasing, there are more technology risks, risks linked to the complexity of the project teams relationships is increasing as the number of different organisations involved in a same project is increasing, market risks are changing with product development length being reduced.

Tolerance

With every project I start I always ask the sponsors “where is the tolerance?”, they always look baffled. The tolerance is basically deciding, if something goes wrong, what constraints is the most flexible: do I change the scope to meet the time commitment? do stick to the scope and allow some slippage? if I have to stick to the budget then shall I remove some of the scope?

Understanding the tolerance gives the project team so strong indication about the project’s environment and priorities. I found that this is extremely important to focus the team.

One way to visually represents the tolerance and constraints to use a Radar chart with a scale of your own (in our example 0 to 6). The higher the number the more important the constraints. In order example Budget and Resources are set to 6 so it will be hard to change them (upwards of course), Risks are at 6 as well, meaning that trying to not mitigate risks is not an option. On the contrary Quality has a low number, meaning that if the quality of the end product suffers then it’s “OK” (not sure if that’s a real life example!).

I had a couple of “Twitter” discussions recently about agile vs. ‘traditional’ approach to project management. Traditional means Waterfall for most people (including me), at least in IT.

One of the discussion was about using Agile with Fixed Price contracts.

Usually Fixed Price contracts means that all requirements are known upfront and that a plan is carefully developed from day 1 to project closure in order to make sure all costs are understood, and that total project length is figured out (both to plan resources needs and to avoid late penalties).

Fixed Price contracts also usually operate under a tight Change Control mode, and Changes are not usually welcomed: they disturb the work currently being done by the teams, indeed, the current plan does not contain time to analyse change requests which therefore could be seen as a threat to the execution of the project. One the other hand the customer knows that changes usually means good margins for the supplier.

This tends to go against some of the agile principles about welcoming changes and iterative planning with re-assessment of the scope and priorities at each iteration (for Scrum anyway), also fixed price projects are ruled by the “Contract” and not the “Customer collaboration”.

However this is not impossible and I could find a number of positive experiences (or seemingly).
In this post it is argued that fixed price contracts have better outcome with Agile practices.

I won’t pretend to know the “Final answer”, I am only keen to contribute to the debate. My experience and my observation of the industry I am in: essentially Systems integration for Telecoms operators tells me that there are two hard facts that are HUGE blockers to using Agile for Fixed Price contracts in my industry:

Blocker 1: The project is driven by the contract and both parties are focusing on “what’s in their” for them in the contract. This is the hard reality, a requirement is a requirement, a date is a date.

Blocker 2: The buyer is NEVER organised to cope with Agile techniques of continuous integration, continuous testing. Go and ask a Telecom operator to put something live every say one month over a period of 6-9 months and ask them to validate the deliverables throughout the project. This will (almost) NEVER happen due to all live operational constraints, test environments availability, resources availability.

Blocker 2 is, in my industry, the key blocker for using Agile.

Thoughts?

I passed my PMP certification with PMBOK® Version 3. One of the frustrations I had with it was Project Scope management knowledge area that was essentially focusing on the Project Scope and not the Product scope. The product scope was acknoledged but still not the purpose of the knowledge area, “This chapter focuses on the processes used to manage the project scope.” (page 104).

I felt we were then taken from project initiation to scoping the work to be done without having a process to capture the product requirements. Somehow it was left as a “lifecycle” decision and loosely documented in the body of knowledge.

The figure below is a summary of how scope is defined in PMBOK® Version 3.

PMBOK® version 4 comes with a number of changes and clarifications about scope management. I am glad that some of the changes addressed my frustrations. The figure below is a summary of scope in PMBOK® Version 4.

So here are the changes:

• There is a new input to the “Develop project charter” process: Business Case. Prince 2 people will be happy as Business Case is pervasive in Prince 2 and only briefly mentioned in PMBOK® Version 3 (note: it’s not because it was only briefly mentioned that it’s not necessary to review the business case throughout the life of the project).
• “Collect Requirements” is a new planned activity in Project Scope Management. It outputs the Requirements documentation. The goal of this new process is find out from the stakeholders the project requirements to be met so that the project will meet its objectives. Stakeholders identification is the purpose of a new process as well: Identify Stakeholders.
• “Develop preliminary scope statement” has been removed – it was seen as delivering similar output that what is found in the project charter.
• “Define Scope” has changed: it takes the Requirements documentation as input and its name has been normalised. The output is the same: project scope statement.

To me the major change is in Define Scope. In version 3, it “develops a details project scope statement”, in version 4, it “develops a detailed description of the project and scope”. The emphasis on the product scope is stronger in Version 4 than in Version 3. In Version 3 the message is to focus on the project scope even though Product Analysis is a Tool and Technique of Scope Definition and Product Scope description part of the Project Scope statement. I always thought that there was an ambiguity about product scope: on one hand it was stated that this was not the focus of the process and on another hand we are given the tools and techniques and output.

With this new emphasis on Product Scope and the addition of the Collect Requirements process PMBOK® Version 4 brings more formalism in product requirements capture and definition as part of the project management processes. Good news!

PMBOK® is a registered trademark of PMI (Project Management Institute)

All too often organisations selling IT solutions ignore the role of project management up until the deal is done and the project is starting. In fact, up until it is too late. Organisation are focused on selling products and licences and ignoring – because it is complex and outside the confort zone of sales department – the integration complexity that would need the inputs of a project manager. Project management is expensive and the pre-sales budget is often not big enough to support this cost.

Amongst the impact of this non-involvement are:

• Missing or wrongly evaluated integration activities
• Incorrect dependencies between activities
• Little (if none) check on resources availability
• Missed scope
• Very difficult start of the project – as the knowledge transfer is delayed until the contract is signed
• Bad customer satisfaction
• Incorrect project budget…very likely overspending

This results in a project that starts on the wrong foot and very often means that the delivery will not match the success criteria established. I always suggest an earlier involvement from project management and a better connection between pre-sales and operations processes.

1. Earlier involvement from Project Management

With a PM embarked in the pre-sales activities (read: not full time, just “as needed”, meaning if the opportunity has been qualified as “complex” and requiring the inputs of a PM) the integration requirements will be reviewed by an subject matter expert, this will ensure that the scope of the integration work is analysed correctly giving the benefits of better work packages estimation, better resources needs estimation, better scheduling. This will massively de-risk the project.

2. Better connection between pre-sales and operations processes

Both do not have to be completly separated. During pre-sales some project work can already be started for example to clarify / validate technical aspects, validate project planning. This is ignored more often than one could think! You’d be surprised. At least the pre-sales should generate the following:

• First version of the Project management plan. Describing milestones up the end of the project (those things are contractual) and detailed planning for the first phases of the project (requirements / design for example), describing the complete set of deliverables, assumptions, constraints and dependencies. The rule here is to use a standard project management plan and decide which section should be described during pre-sales. For example if the human resources skills needed is going to be an issue then it should be explored in more details at this stage.
• Acceptance plan and criteria. They are usually contractual items – so all inputs should already be there
• High-level design of the solution: to remove misunderstanding, validate some design options…it is in fact the result of the engagement of the technical department on the project. It’s good at this stage. This is best done when there an agreed interaction between pre-sales and operational processes. When the flow from one to an other is natural and agreed. This way the same language is used and both departments (sales, operations) AND the customer will be better off.

I successfully took my PMP exam last year. During my preparation time for the exam I had loads of questions about it, I was wondering if I had done enough to prepare for it and in my immediate network no-one had a PMP certification so I could not find someone that could sympathise with me and share with me some tips.

So now that I have my PMP certification, I thought that sharing “how I prepared to the PMP exam” here could be useful to some. So here it is.

What worked for me may not be working for someone else (bit of a disclaimer here). But it’s true, everybody is different and that includes the way we learn. Anyway that’s my PMI-PMP story.

1. Diving in the PMBOK

Although I took the exam in July 2007, I have started preparing for the exam in January 2006. And I started the hard way: reading from A to Z the PMBOK. Although I had skimmed through it in the past, it was the first time that I really started to study it seriously, reading chapter after chapter and writing on a notebook the key learning points for each of them: main processes, inputs and outputs. Taking particular attention on the concept that were not so obvious to me.

PMBOK is full of theory and very little on practice (read: nearly none) to link theory to reality and this is at times hard, specially for the Quality chapter because Quality Control and Assurance are not always easy to separate. The level of abstraction makes it sometimes distant to what one actually does on project.

Although it was a hard read in the end I was glad I did it and that I did it over a long period of time, because with time the PMBOK became slowly part of me. This book cannot be read in two weeks and forgotten about, what worked for me was to read it over a long period of time putting it to practice in my day to day job. I let it “sip” into me with time.

2. I need those PDUs

To take the PMP exam one need to bring 2 things on the table:

• a proven – documented – PM experience (that could be audited – actually mine was), make sure you keep in touch with your old bosses to ask for references. I did.

• 35 contact hours: training from a registered education provider (REP). I used RMC online training.

Again it took me some times to complete the training, the training was not very engaging, using mostly old web technologies, the introduction videos for each chapter was nice but overall I found it hard to go back to my computer and learn. The format was not engaging enough.

Anyway I completed the training, used the prep-exam questionnaire to death and got my minimum PDUs. It took me about 6 months to finish the training, I was very busy at work and my free time was limited, this is why it took so long.

3. Exam preparation in sight

After reading the PMBOK and doing my online training I decided to book a date for the exam. Things were getting more serious, by setting the end date I was more focused (surprise! surprise!). For this final preparation I went back to PMBOK, reading it on my way to work every morning.

When the date came closer I was working on it every morning for 2-3 weeks (I took some time off). Every morning I will sit with 3 friends: the PMBOK, the Definitive Guide to Project Management and The PMP Exam: How to Pass on Your First Try.

I read again the PMBOK chapter after chapter (based on Knowledge areas) taking pics at the other 2 and restart taking summary notes in a notebook.

The PMBOK is the most comprehensive document here, but as it does not come with guidances, tips or examples the two other books were very handy.

The Definitive Guide is a good book, giving you a good summary for all areas but it is not 100%PMP focused and by far not sufficient to prepare the exam, it is just too light in content. However I still found it useful. It is a good introduction before getting into PMBOK.

The last book, The PMP Exam: How…, is very very targetted to the exam, insisting on areas that one should take particular attention for the exam, very focused on tips about the type of questions you can expect. It comes with access to an online prep-exam system that was very useful. This book really helped building my confidence for the exam by its direct approach. It was the natural link between the theory of the books and the exam itself.

4. The exam itself

I took a morning exam. Got a big breakfast, got a good night sleep the night before (and the one before). It is hard to be relax for the exam, but I was also excited by it, excited to see the result of those months of learnings. It was time for me to take it and make it a success. I was ready.

2 things surprised me at the exam:

• The questions were somewhat different to the questions I faced during my practices exams with RMC or with the Prep Exam book, overall questions were slightly more difficult at the exam. So I think that is something you need to prepare yourself with.

• It took me the full time allocated to complete the exam, including a full review of each of the questions I had marked for review. Almost the full time allowed, maybe I had 5 minutes free in the end but not much more. They say work expand to the time allocated (Parkinson Law) – it’s was true for me here.

So that was my PMP exam story, I hope yours will be / has been as succesfull as mine.