ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs A Holistic Look at Program and Project Constraints
Saturday, 10 July 2010 05:00

A Holistic Look at Program and Project Constraints

Written by  Gary Hamilton, Gareth Byatt, and Jeff Hodgkinson
Rate this item
(0 votes)
The Triple Constraint of managing the interaction of time, cost and scope is a familiar model to most Program and Project Managers.

Delivering projects on time, within budget and per an agreed scope can be considered to be a “good result” by the project team. But effectively managing these constraints does not guarantee that the project is deemed a success by all of its stakeholders. Additional project constraints need to be taken into account to determine whether “complete” project success is achieved.

A general starting point for these additional constraints is this: think about the longevity of the project’s end output. Take a moment to think about projects you have been involved in, or known about, that finished 12 months ago or longer. Did they deliver their end output on or before schedule, on or below budget and did they fully meet the requisite expected level of scope and quality? If so, great. Now fast-forward to today. Do you know how well the end output of that project is being used? And does it contribute to the organisation in the way that may or may not have been originally anticipated?

History has many examples of projects that had a rocky ride until their completion, only to see the end outcome be fantastically successful over a period of time. For example, consider the Sydney Opera House. The design was very challenging to build, and for various reasons the project was completed well over time and budget. Not a great start to its life. Today, this iconic building is one of the most visited landmarks in the world and is considered an icon of Sydney, and Australia. In retrospect, if you queried the project’s stakeholders today, arguably all would agree that regardless of the time and budget overrun, the project has been a great success.

Our take-away messages from this article are as follows:

  1. A project’s success depends on how well positioned its end output is placed to enable long-term benefits to be derived, and how successfully these benefits are then achieved over the lifespan of its use
  2. If your project is part of a portfolio and/or program of works, its success needs to be measured by how well it contributes towards the portfolio and/or program as well as how successfully it is delivered in its own right

Please note that our article does not seek to supplant the Triple Constraint as a principle. Instead we put forward some suggestions on additional constraints that impact project success.

Here are our main Pointers for consideration:

  1. A project’s budget, schedule and scope need to be aligned to the overall benefits of the intended output using benefits management
  2. Customer and Stakeholder satisfaction should be measured with a view to delivering the agreed benefits during the project and the operation of its end output
  3. Integrating the project into the organisation it is being delivered for depends on successful implementation planning (if your organisation has a Project Management Office, its level of maturity will impact this)
  4. Managing risks (positive and negative) throughout the project should “focus people’s minds”
  5. Team dynamics, the organizational structure in which the project exists within and the methodology used to implement the project are important constraints that impact project success

Our “double tetrahedron” below describes the main elements to these constraints:

long-term-success

Let’s look at each main point in turn:

  1. A project’s budget, schedule and scope need to be aligned to the overall benefits of the intended output using benefits management

To manage a project to budget, schedule and scope is of course important; nobody will dispute that. But take a moment to consider how focusing entirely on these three constraints during design and build (or implementation) can potentially create a “blinkered affect”, which could have a detrimental affect on the long-term use of a project’s output and the benefits it is intended to provide. What if, mid-way through implementing an agreed element of design, your team is faced with a choice on “which way to build to scope”? Choosing Option A is easier for them, and it allows you to keep on schedule and budget; choosing Option B will throw you off course, be a hassle to an already busy team, but – and here’s the but – if you think hard about it, you know it is the best option for the end Users of your final product. In such situations it is worth pausing for a moment, consulting key stakeholders and making the best choice for the longevity of the product – be it Option A or B. Think hard about the end benefits your project is designed to provide. As long as you have good project management processes in place you will be able to manage any scope, budget and/or schedule change through change control procedures.

  1. Customer and Stakeholder satisfaction should be measured with a view to delivering the agreed benefits during the project and the operation of its end output

This statement stands to reason, but it is not always easy to achieve – it needs focus early. The devil is in the detail. Reaching agreement on the right measures (be they Key Performance Indicators, KPIs, or “Satisfaction Measures”) to track, during a project and once its output is in use, should be a key part of your project planning. The measures you agree are project constraints. Large projects with many internal and external stakeholders will inevitably have many needs, and as a result it may not be practical to report all KPIs to all stakeholders – some KPIs will be relevant to a particular group, others will not be. The type of industry you are working in has a large bearing on the measures used as well. Consider whether customer and stakeholder satisfaction is dependent on “external constraints” of other projects within a program or a portfolio. If it is, understand what these constraints are and how your project influences, and is influenced by them.

 

  1. Integrating the project into the organisation it is being delivered for depends on successful implementation planning

In our parlance, “Implementation Planning” is about setting up the organisation structure so that when the project’s end output is ready for use (be it a new car design, an IT system, a new hospital), the organisation can maximise its adoption. For example, making sure that customer support networks are in place, and/or that ongoing product management will ensure the new product/output is continually improved and maintained. Your project may well be part of a Business Plan that requires several projects to be integrated to achieve “maximum value”. Thus, understanding these dependencies (or constraints) is vital to its success.

Whilst Implementation Planning may not seem like a direct constraint to a project whilst it being built (or configured), it is – because if you do not give is adequate focus during your project’s delivery phase, your Customers and other stakeholders may not have the right level of “urgency” and desire to ensure the project’s efforts are geared towards the best long-term outcomes for their organization(s).

  1. Managing risks (positive and negative) throughout the project should “focus people’s minds”

Effective project risk management is generally recognised as a key determinant of project success. Risk management is more than maintaining a Risk Register; it is about ensuring that all opportunities and threats are being constantly monitored, with effective strategies to deal with them being agreed and implemented.

Risk management is a key constraint to delivering a project and the way you manage risks, and the appetite for risk that your key stakeholders have, is an important determinant of success.

  1. Team dynamics, the organizational structure in which the project exists within and the methodology used to implement the project are important constraints that impact project success

 

Let’s consider each of these three “perimeter constraints” in turn, and how they play their part to affecting your project’s success.

 

Team dynamics refers to the way you work as a team. Consider the way your team is or will be structured – is it a flat or steep hierarchy (each has its own merits depending on the project)? How dispersed are your team members – across the world or a country, or in the same office? How many different organisations are represented in the project team (for example, is it a joint venture)? All such factors are constraints to manage.

The organizational structure in which your project operates refers to the “larger structure” of your parent organization or organizations. Is it a functional structure, where functional managers have most say and power in how things are run, or is it a projectized or matrix structure where Project Managers have more formal power?

 

Lastly, project implementation methodologies vary across different disciplines, be it manufacturing approaches such as lean thinking or Kanban/Just In Time, or IT processes such as “waterfall or agile”. Overlay onto that general principles of project management, such as project phasing and the structure of governance. Whichever methodology is agreed is a constraint to be managed.

 

In conclusion, managing project constraints of time, budget and scope is important, but managing these constraints effectively does not guarantee success in the eyes of all project stakeholders. Other constraints meld into these and affect a project’s success. We suggest that important other constraints for consideration on most projects are:

  1. Aligning budget, schedule and scope to the overall benefits of the intended output
  2. Measurement of Customer and Stakeholder satisfaction
  3. Implementation planning to integrate the project into the organisation it is being delivered for
  4. Managing risks (positive and negative) throughout the project
  5. Managing team dynamics, the organizational structure in which the project exists and the project methodology used

 


 


Bios:

Gareth Byatt, PMP is Head of the IT Global Program Management Office for Lend Lease Corporation. Gareth has worked in several countries, and is currently located in Sydney, Australia. Gareth has 14 years of project and program management experience in IT and construction. Gareth can be contacted through LinkedIn. Gareth holds numerous degrees, certifications and credentials in program and project management as follows: an MBA and first-class undergraduate management degree, PgMP®, and PRINCE2.


Gary Hamilton is the Manager of the PMO and Governance within Bank of America’s Learning and Leadership Development Products organization. Gary has 14 years of project and program management experience in the IT, Finance and HR. He has won several internal awards for results achieved from projects and programs he managed. Gary can be contacted through LinkedIn. Gary holds numerous degrees and certifications in IT, Management and project management which include: an advanced MBA degree in Finance, PgMP®, PMP®, PMI-RMP®, ITIL-F, and SSGB. Look for Gary at the PMI Global Congress 2010-North America.


Jeff Hodgkinson is the IT Cloud Program Manager for Intel Corporation. He is a 30-year veteran of Intel Corporation with a progressive career as a Program/Project Manager. He is located in Chandler, Arizona and also volunteers in various support positions for the Phoenix PMI Chapter. Jeff was also the 2nd place finalist for the 2009 Kerzner International Project Manager of the Year AwardTM. Due to helping people achieve their goals, ‘Hodge’ as referred to by his many friends is one of the most well networked and recommended people on LinkedIn. Jeff holds numerous certifications and credentials in program and project management as follows: CCS, CDT, CPC™, CIPM™, CPPM–L10, CDRP, CSQE, IPMA-B®, ITIL-F, MPM™, PME™, PMOC, PMP®, PgMP®, PMI-RMP®, PMW, and SSGB. See Jeff at the PMI Global Congress 2010-North America as he will be co-presenting a paper on, "Value of the PgMP® Credential in the Working World".

 


Attribute Level

CI (Customer Impact) Factor

TS (Technical Severity) Factor

1

7 =

Directly Affects Major Customer’s Business Objectives

Directly Affects Revenue

Required/Affects most/all of the company

Negative Impact to your organization and/or business

No Solution and/or no progress and the is solution overdue

Group has high degree of influence / impact to effect change or solution

Great time investment

4 = No known technical solution or owner at the company

2

5 =

Customer business impacted without requirement

Direct Impact to IT Organization and/or Business

Commitment made by org but not being implemented

Required/Affects multiple customers and sites

Solution in progress

Completion date unknown

Group has some degree of influence/impact to effect change or solution

Good time investment

3 =

Some technical investigation, theory, or direction as to fix.

Technical Solution Owner(s) identified

3

3 =

Customer can work without this requirement /request

Solution in progress and completion is date known

Required by single customer or unique need (small scope)

Project Team being formed

No resource or funding

Group has little degree of influence/impact to effect change or solution

Questionable time investment

2 =

Technical Solution currently being designed.

Could be near Alpha quality

4

1 =

Solution done – in maintenance or monitoring mode

Project Team (resourced/funded) working on implementation

Solution in place & monitoring progress w/ customer/supplier

Group has no degree of influence or impact to effect change or solution

Poor time investment

1 =

Technical Solution currently being designed.

Could be near Beta quality.

Solution currently being tested or implemented.

Technical Work-around exists / usable

Read 4598 times Last modified on Wednesday, 27 October 2010 15:15
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 393 guests and no members online

Got something to say?