I personally think they're a bit under-nourished in the general scheme of things. I'm not at all certain that within most projects there's a consensus on what a constraint is. There's often little or no effort to record or track constraints.
I think most projects face constraints in various forms, but there are three in particular which are almost omnipresent.
Before I go too much further, I suggest that unless you're intimately acquainted with Eliyahu M. Goldratt's theory of constraints, there's no better time than now to hop on over to Wikipedia and brush up on what I think is some pretty smart thinking about the way the world works.
All the way back in 1984, Mr. Goldratt was putting pen to paper and publishing material that included the following:
Types of (internal) constraints
- Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods/services.
- People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.
- Policy: A written or unwritten policy prevents the system from making more.
*Source - Wikipedia
I don't have too many unbreakable golden rules but I do take the time to reflect on these three constraints roughly speaking at the following junctures.
- Spend approval
- Project start-up and initiation and every subsequent stage boundary
- All discussions relating to project change
The effective delivery of change can be hindered by simply not having the tools for the job.
Whether this is heaving lifting machinery, the right widgets, collaborative toolsets for the project team or specialist software tools it matters not.
How to defend against deficiencies in equipment? Good planning principally. Not altogether intuitively, a detailed product description can often identify the particular equipment requirements for the delivery of a product.
The PMO too (if you have one) should be a source of lessons learned, historical data, policies and standards of its own that illuminate requirements for equipment.
Lastly, subject matter expertise is often the differentiator between getting things right the first time or slowly learning the right way through time and patience.
Your approach (as ever) should be proportionate and informed by risk.
I've seen a few of ways in which absence of policy can seriously undermine project success.
- The output of a project isn't used due to a lack of policy
- Resources cannot be brokered for a project due to lack of sponsorship
- Lack of stakeholder engagement (because no one's telling them any different)
The really simple answer (really far too simple) is simply get a clearer than clear project mandate. I've yet to see one. The less simple and less effective answer is wrap your project's mandate up in a terms of reference (PID probably, charter or brief maybe) and get that approved, authorised and sponsored.
If you're still worried, add it to the issues log - this won't help ever so much potentially, but you will have done your job as a project manager to the degree possible.
There's a bit of an addendum to this as well. There's (certainly in the UK public sector) an increasing drive toward the management and realisation of benefits (at last!). This can help the mandate / policy quagmire as all of a sudden, staff outside the project team are likely to be accountable for the delivery of benefits and this might get you an entry point to a discussion about policy / mandate or lack thereof.
You could spend a lot of time discussing the various human fallibilities that can constrain a project's success. I think there are pretty much three principal headings.
Responsibility assignment matrixes are (I think) very important in most projects. Projects are temporary, unique and time-bound (aren't they?). Thus, it is not reasonable to require a team to know what is expected of them unless they're told. And, in my sometimes prescriptive and process orientated world, telling people anything important should be documented, versioned and recorded.
I like the RACI chart - there are others.
Use a skills inventory. A skills inventory is a system or tool that identifies the skills and skill levels required to deliver your project, programme, specific work packages or products. It may also specify the individuals who possess those skills. Skills inventories are most effective if they are aligned with a particular programme.
I don't think it will often be within the scope of project manager's accountabilities to influence or manage cultural change within a project or programme team. I think this is one of those situations where if the culture isn't (for instance) delivery focussed, then you'll need to adopt a suitably appropriate posture to ensure the project's objectives are still attainable.
As far as availability is concerned, I cite the following.
- Planning is criticial, as is estimating and forecasting. If estimating and forecasting is to be worthwhile, it must be based on historical data. One of the jobs of resource planning must be to specify what is actually going to be required in terms of resource burn.
- Sponsorship from resource brokers (see policy above). This should be two fold. First, to release the resources for the period specified at the time specified. Secondly, to deliver (as far as possilbe) the scope of work agreed to schedule, cost and quality.
- Manage change and issues so that deviations from what is agreed is predicatable, sustainable and planned.