Be Careful Which Project Constraint you Measure, as You Might Just Get It
It is a commonly held belief that in the absence of a higher driving need, people will focus on those activities or behaviors for which they are being measured and subsequently either positively or negatively reinforced. Given this premise, it should be no great revelation to leadership teams that if a balanced approach is taken by governance bodies to project oversight, this should result in a correspondingly greater incentive for project teams to consistently perform practices across all key project management knowledge areas.
This is why it never ceases to amaze me that the same senior stakeholders who complain about the lack of practice consistency across their project teams with regards to certain knowledge areas are equally guilty of forcing these same teams to focus on one or two specific constraints.
Please note that I’m not referring to the practice of communicating the priority of project constraints as it relates to the business objectives or key drivers for a project. That is an essential activity which will ensure that project and governance teams make the right types of trade-off decisions. For example, if a particular project is addressing a time-sensitive regulatory requirement, schedule is the primary driver and it is perfectly reasonable for the project team to propose decision recommendations which will protect project deadlines at the cost of other constraints such as scope or cost.
However, should an organization focus exclusively on one or two constraints across all projects in the portfolio, this can result in a culture which colors not only team decision making, but also the degree to which they comply with the company’s project management methodology. While you might feel that a safety measure to guard against this outcome is regular project assurance reviews or audits, non-compliance findings which are unrelated to the supreme constraint are likely to be marginalized.
A common example of this behavior occurs in companies which are under sustained financial pressure or scrutiny. The last decade has not been kind to both public and private sectors, hence it is little surprise that cost is king. You might feel that regulatory projects or product development projects would give time a higher priority, but even on those, it is rare to see governance oversight bestowing financial carte blanche on teams just to hit a date. Budgeting, financial tracking and reporting are usually performed quite diligently as there is significant oversight in that area, but the same is usually not observed across the remaining knowledge areas.
While you might feel that this neglect may apply to practices such as risk or quality management, it might even be identified on the stereotypical project management practices of time or scope management. This is certainly not to say that teams are ignoring milestone delivery dates or customer requirements. Results are still being produced but they might not be delivered following consistent practices.
If you are still skeptical, do a spot check on your own project portfolio:
- Identify a sample subset of your active projects which is representative of the overall portfolio in terms of strategic alignment, drivers, and functional representation.
- For each of these identified projects, check for the existence of a critical (as per your methodology) artifact which supports each project management knowledge areas. For example, for scope you could look for a work breakdown structure or other type of scope decomposition document. For stakeholder management, check whether there is a detailed, up-to-date stakeholder analysis register.
- Review each artifact you are able to locate for both quality and currency of data. You could use a very simple rating as follows:
- Up-to-date, high-quality content
- Somewhat out-of-date, or somewhat inaccurate content
- Completely out-of-date, totally inaccurate, or missing
- Once this has been done for all projects and all knowledge areas, analyze the results for a pattern of diligence in one area and poor compliance in others.
If you have identified that there does seem to be an unhealthy focus on one constraint, you will likely want to review the implications of this with your senior management team. If nothing else this gives you the opportunity to conduct a leadership gut check to help you determine whether there is real commitment to establish or improve organizational project management capability.
This might also provide you with a good coaching moment to debunk the myopic view that one can safely neglect certain project management practices without causing an impact to the “chosen ones” – as we all know, there is a very tight dependency between all knowledge areas.
W. Edwards Deming is often erroneously quoted as having said, “You can’t manage what you can’t measure.” In fact, he stated that a cardinal sin was trying to run a company based solely on reported measurements. The same could be said of an excessive organizational focus on one constraint.
Don’t forget to leave your comments below.
ดูบอลไทยลีก
… [Trackback]
[…] Information on that Topic: projecttimes.com/articles/be-careful-which-project-constraint-you-measure-as-you-might-just-get-it/ […]
สล็อตเว็บนอก
… [Trackback]
[…] Find More Information here on that Topic: projecttimes.com/articles/be-careful-which-project-constraint-you-measure-as-you-might-just-get-it/ […]
Dan Helmer
… [Trackback]
[…] Find More on that Topic: projecttimes.com/articles/be-careful-which-project-constraint-you-measure-as-you-might-just-get-it/ […]
fortnite hacks
… [Trackback]
[…] Here you can find 94761 more Info to that Topic: projecttimes.com/articles/be-careful-which-project-constraint-you-measure-as-you-might-just-get-it/ […]
eagle rare whisky
… [Trackback]
[…] Read More on on that Topic: projecttimes.com/articles/be-careful-which-project-constraint-you-measure-as-you-might-just-get-it/ […]