Posts Tagged With: Project management terms

A risk management ode to project managers!

Father’s Day might be a holiday which is much newer than the project management profession itself, but let’s not miss the opportunity to celebrate the many ways in which project managers help their projects succeed through effective risk management.

F is for Failure Mode and Effect Analysis, which can be a mouthful to say,

A is for avoidance to hold critical risks at bay,

T is for risk transfer for which we’ll have to pay,

H is for human bias, which can stand in risk management’s way,

E is for expected monetary value analysis, which calculates outcomes come what may,

R is for reserves, which prevents realized risks from ruining our day,

S is for simulations like Monte Carlo for us to play,

D is for Delphi where estimators go to pray,

A is for assumptions which come in many shades of grey, and

Y is for yellow which our project dashboards should never display.

Happy Father’s Day to all!

 

Categories: Project Management | Tags: , | 1 Comment

So what’s in your company’s project management dictionary?

dictionaryWe often joke that the only correct answer to a project management question is “It depends!“. Many of us would also agree that the right approach to deliver a project is one which is tailored to fit its context, complexity and the culture in which it will be managed.

But there is still value in establishing some standards for project management. One component of such standards is a set of operational definitions. Such definitions might constrain the degree of flexibility which a project team possesses but will support governance and oversight through increased consistency and predictability.

Like everything else, operational definitions need to be established selectively.

Let’s consider a team’s degree of confidence in its estimates. A project funding policy might require that team submitting detailed estimates should have a confidence of ±5% but what does that really mean? Until the project is over, we won’t know and punishing the team for being of that range will be a Pyrhhic victory. If a sponsor is putting undue pressure on a team to deliver, they are going to be hesitant to declare that they have a low degree of confidence and will value short term peace over long term pain.

But what happens if we don’t develop operational definitions for the following terms?

Project

PMI and other associations have provided criteria for differentiating projects from other activities (e.g. unique endeavor, start and finish) but these criteria are insufficient for implementation purposes. Without establishing some quantitative measures (e.g. effort, cost) to accompany the qualitative ones, the risk of significant changes being managed in an undisciplined manner increases as does the likelihood of financial and resource capacity erosion to stealth work.

Program

Many companies will identify programs the way Alan Novak spoke of pornography: “Mr. Justice, you will know it when you see it.“.  In the absence of an operational definition, the risk increases that an initiative which would have been better managed as an integrated set of projects with appropriate governance will be undermanaged resulting in reduced business outcomes.

Issue or risk severity and probability

What does “High” mean? Individual biases skew the analysis and perception of risks or issues so providing quantitative thresholds can reduce the potential for critical risks or issues being ignored or unwarranted effort being spent on low value ones. But simply translating risk probability from words to percentage values won’t help as our biases would continue to influence our assessments.

Project manager

There is no simple litmus test for what makes a competent project manager. However this should not deter organizations from establishing a minimum set of qualifications to prevent this scenario from a 2011 Dilbert comic. Without this, there is a greater likelihood of project failure and reduced credibility in the profession.

Companies need to establish reasonable operational definitions for project management – adaptability should never be confused with anarchy!

 

 

Categories: Project Management | Tags: , , , | Leave a comment

Avoid gold-plating through agile delivery

goldplateAs it is with jewelry, on projects gold-plating is all form with no substance. The increase in costs is rarely justified by the value provided by superficial “bling”.

It could be an analyst adding in requirements which they came up with on their own without ensuring that those are actually required, a developer who introduces a code change or feature they believe is useful without checking with others or a quality control specialist who decides to test above and beyond approved test plans.

Don’t get me wrong – the intentions are usually good and I’ve yet to encounter an instance of gold-plating which was done maliciously. But it doesn’t matter – gold-plating is work creep.

What’s the worst that could happen you ask?

On a project which follows a traditional or waterfall delivery approach, that innocent feature which the developer added might cause regression to approved functionality but at the very least when it finally gets identified will generate unplanned work for other team members. Scope definitions, requirements documentation and other work products which had been produced, reviewed and formally approved will have to be revisited. And the magnitude of the rework and incremental effort increases the further the project gets into the delivery lifecycle.

But on an agile project, if a work item is elaborated beyond the Definition of Ready or the Definition of Done, this will become apparent a lot sooner. Increased transparency into all development activities reduces the likelihood that such changes will propagate beyond the iteration in which they were introduced. Non-solo development practices such as pairs programming can weed out gold-plating at point of application.

A good agile project team exhibits self-discipline and self-organization. Behaviors which impact the team’s ability to meet its iteration commitments will be addressed swiftly else velocity will decline.

And let’s say the team member who is tempted to gold plate feels very strongly about the specific change they’d like to make. Unlike on a traditional project, there are ample opportunities to review it with the product owner, analyst and other team members to assess whether it merits being added to the work backlog.

Using agile approaches to deliver a project provides no guarantee that gold-plating won’t occur. After all, it is a function of human behavior, not approach or methodology. But agile lifecycles can make it easier to detect and prevent future recurrence.

Categories: Agile, Project Management | Tags: , , , | 1 Comment

Create a free website or blog at WordPress.com.

%d bloggers like this: