Top Tags

The (New) Hierarchy of Needs – Part III

[This is part three of a series on project management that is based upon Abraham Maslow’s “Hierarchy of Needs”]

Constraints

The next level “encapsulates” mission and objectives within the triple constraint: timescopebudget.

When the topic of project management comes up, one of the fundamental concepts is the triple constraint.  Needless to say, truly understanding the triple constraint and having a subsequent dialogue about each constraint is key to the success of the effort.  Interestingly enough, many assumptions are made during this dialogue that can introduce problems down the road.

For example, instead of asking which constraint is “variable”, it’s sometimes best to ask the question – if we don’t do X, what is the impact?

  • Timeif we can’t finish this by X, what happens?
  • ScopeIf we cannot deliver X1, what happens?  What if we deliver X1-Y instead?
  • BudgetIf we go over budget, what happens?

It’s recommended that the PM challenge the constraints as much as possible.

The customer may say that the effort must be delivered by date X, but if we fast forward to date X and the project isn’t delivered, what is the course of action?  If there isn’t a defined course of action, then that really isn’t a hard and fast constraint.  If there is flexibility, then it’s best to make it apparent.  Use the constraints to your and the team’s benefit.

Another aspect of this discussion is to think about the triple constraint when things aren’t going well.  If it takes an additional 10 resources to finish the project by time X, will the business still benefit in the long-run?  Scenarios like this should be discussed and planned for in advance so that you have some boundaries that you can work within.

Storytelling

The next level focuses on “storytelling” – describing the project lifecycle and the end-goal in such a way that is easily comprehensible by all involved.

Requirements are typically seen as the central “core” around which all work is driven from.  Regardless of the analysis methodology employed, leveraging “static” requirements as the basis for all work is not ideal.  The reason for this is that people do not think linearly – and traditional requirements gathering is just that.  Since this is materially different from how people think, gaps are likely to arise which can cause downstream problems.  Instead, a recommendation is to employ different “storytelling” methods to describe what the end functionality should look like.

These “stories” can take multiple forms:

  • writing out in paragraph form what the end functionality looks like.
  • creating individual “stories” that align with each objective.
  • describing the objectives using a mind-map.
  • describing how the project progresses over a period of time.

Creating a story isn’t necessarily mutually exclusive from creating requirements – but the story can ultimately build a better framework from where the requirements can exist.  Remember, you aren’t here to create “shelf-ware” – you’re here to create documentation that is going to drive action.

Ultimately, true comprehension comes from natural prose, not bullet points – tell the story first.