Blogged on:

Seventh and Eighth Constraint

In a previous blog post I discussed the constraints that exist according to current PMI methodology. It includes Cost, Time and Quality. That are the most well known and make up the elementary understanding of understanding of constraints. In a project, you can choose any two constraints and a third will get squeezed out.

The next level up- let’s call it secondary tier level of constraints, of which there are three more. Risk, Resources and Scope. According to the PMBOK guide, once again, you can choose any two of the triangle and a third gets squeezed out. This is a little more indepth than the previous blog post, because in this we recognize there distinct relationship is not between 6 constraints, but two relationships between 3 constraints concurrently.

6 constraints

After giving this some thought, I have a recommendation that might be polemic in the PM world: There are two more constraints! Specifically they pertain to professional service project delivery: They are Change or Improvement and Customer Satisfaction.

The two constraints are unrelated to each other as much as they have a relation to risk- that is to say they are more specific components of risk. The Change and Improvement could rightfully go into the Cost/Time/Scope triangle making it two quadrangles that interact concurrently- but perhaps I will explore that in a future blog post.

8 constraints

Customer Satisfaction

This is a conceptual reflection of the level of satisfaction that those who are acting as the client of the project currently enjoy. In product based environments (as opposed to service based), the client might be endogenous (i.e: product management), while in service based environments, this would be exogenous.

For our purposes, the role of the customer is a stakeholder who furnishes the business objectives, signs off on functionality and scope, and has sign off for acceptance of the final deliverables, which can include either product or service based operations. For further elucidation on the roles of team stakeholders, please refer to Section 2.2.1 of PMBOK 5th Edition. (p. 32).

Customer satisfaction can typically be assumed has a direct relation with scope, and inverse relation with time and budget, but beyond that can be independent in traction and loss. It can be a reflection of controllable actions on the Project Manager’s part- such as clear communication, ability to effectively manage expectations, or by influences clearly out of the project manager’s scope of ability to control- such as changes in the value of that the client will derive from the solution.

The changes in value that the client assumes from the solution can be a result of changes in competition or other market forces, or negligence in articulating demands in necessary functionality. The point is- the Project Manager can pick up the phone one day and find the customer on the other side very unhappy, and it’s up to the Project Manager to use all the tools at their disposal to ensure the client satisfaction constraint is handled and under control to reduce the risk of deliverable rejection, project abandonment, etc… (all of which are project extinction events, so they are off the charts in terms of the risk impact).

Client satisfaction can be affected by both normal and super normal events over the course of the project. (Normal events occurring as a result of normal execution of of the project, and super normal events occurring outside the course of normal execution of the project).

Client satisfaction in normal events can be managed effectively through effective expectation management. This can come in the form of something as simple as timely response to client enquiries, reasonable preparation for meetings and regular updates of project documentation such as status reports. While optics are important, a PM who fudges the numbers to come out ahead of schedule and under budget will eventually have their prevarications catch up with them.

The good news, in my experience, if you do your research and due diligence and are able to foresee slips in timeline and budget coming down the pipe and approach the client with options or a solution well ahead of time, and are armed with a good defense for the reason behind the deviation from estimation, any loss in client satisfaction will be short lived.

Change & Improvement

Change and Improvement is a fact of project management. In most organizations, the KPI’s have to show a constant increase in performance. One fairly competition minded adage states that if you’re not improving constantly, you’re losing market advantage because your competitors are. (I think it might have been in my strategic management class in my MBA). At any rate- constant improvement is a fact of life in most organizations. Dealing with change is another reality.

The ability to adapt to change and improve performance in the project actually takes a significant amount of effort in both planning (from the PM perspective) and the execution (from the team perspective). This takes up finite pools of time and effort that can be used fulfilling scope or quality of the project. Even on a micro level- adapting a process to meet the operational needs of that project is going to create a certain level of chaos that you and the team will have to grapple with.

It’s likely not going to cripple the organization if you deprioritize this constraint, even on going, but it’s useful to keep this in mind as a higher level constraint.
Depending on the change and improvement needs, it might make sense to make it a priority. If the team is process free and chaos and confusion reigns, investing in the pain and effort of establishing and enforcing processes could pay off extremely quickly.

In conclusion, looking at the 3 constraints is simple, the six constraints is advanced- if you’re ready for something that will really bend your brain- start looking at two more as constraints that you can enter into play on your projects.