Easy in theory, difficult in practice

Review almost any project status report or project portfolio dashboard and apart from the names of the projects, the next most common field is likely to be a health indicator depicting project health using red, amber or green stoplights.

While these indicators might seem like a good visual method to quickly understand the health of an individual project or a portfolio, the flaw with this approach is that this is a subjective evaluation usually conducted by either the project manager or the project sponsor. 

While one might argue that these are the two roles best positioned to assess a project’s health, they are also the ones who have the most “skin in the game”, hence, depending on organizational culture and project management maturity, the ratings provided may be as suspect as team members’ use of percentage complete for reporting task progress.

At one extreme you’ll find the project managers and sponsors who are eternal optimists or those who fear repercussion if they report their projects as being amber or red – with such individuals, a project’s health will rarely be seen to stray from green until it is past the point of recovery. 

At the other end of the spectrum are those Chicken Littles who set their project to cherry red the moment they encounter their first issue.  Although most people fall somewhere between these two extremes, natural biases make it hard for stakeholders to truly understand project status, and this difficulty increases when the evaluation is done at an overall portfolio level.

To bring objectivity to the health evaluation process, the use of earned value metrics, standardized healthcheck questionnaires to score the health of the project, and other evidence-based inputs such as the number of open high severity issues or risks which don’t have approved response plans in place should all be considered.

However, not all projects are equally important, and a single quantitative health indicator does not help a governance committee to identify which projects truly require assistance.  Given this, there is value in considering the use of two separate indicators – the first provides a quantitative health score for the project while the second normalizes this score by incorporating the relative criticality of that project to the overall portfolio.

While colorful health indicators can certainly create artistic dashboards, an objective evaluation of project health can help your leadership team overcome the impacts of rose-colored glasses and color-blind stakeholders!

(Note: this article was originally written and published by me in March 2013 on my personal blog, kbondale.wordpress.com)

An unfortunate analogy that can be made of project managers is that in many respects they are like worrying parents.  They invest a significant amount of effort, credibility and emotion into the nurturing of their projects, so anything that is likely to impact the success of their offspring is going to affect them in a very similar fashion.

There is a broad range to this type of behavior – some parents (usually those who have more than one child) are mature enough to monitor things from a distance but to also be prepared to act if required whereas others micro-manage their kids lives to the point of almost smothering them in bubble wrap! 

The same can be said about project managers – some trust their team members and stakeholders to be professional enough to come to them proactively when concerns are identified, whereas others won’t be comfortable if they are not constantly touching base to make sure all is well. 

This behavior extends beyond risk and issue management to quality – just as some parents have the need to mold and hammer their children to fit the parents’ vision of how they should turn out, some project managers exhibit the irresistible urge to constantly tweak or tune deliverables, frequently alienating their teams in the process.

While such behavior is detrimental to healthy team development and the perceptions created can linger well beyond the lifetime of an individual project, it is also not conducive to a good work-life balance. 

Project managers who demonstrate the compelling need to stay on top of absolutely everything and to worry past the point of reason can end up neglecting spending quality time with their families or their own professional development.  When challenged about their lack of attention to these critical activities they will rarely indicate that they felt they could have taken an alternative course of action.

Should a project manager be vigilant and take ownership for getting actions, issues & risks addressed – absolutely, if not, they will likely satisfy one or more of Neal Whitten’s ten signs of “too soft” project management behavior!  However a project manager also must recognize the limits of their ability to positively influence project outcomes – in spite of these efforts, the project may still suffer for reasons outside of their control. 

This is where that critical but elusive project management competency of judgment is required to help them accept the things they cannot change, draw on courage to change the things they can and have the wisdom to know the difference.

(Note: this article was originally written and published by me in April 2013 on my personal blog, kbondale.wordpress.com)

This thing we do can often be very challenging – having to deal with suspicious sponsors, squabbling stakeholders and Teflon team members can make us question our rationale in choosing this over any number of other professions.

To counter such thoughts, let me provide some reasons as to why, while frustrating, project management is also fun!

P is for People, without which our projects won’t succeed

R is for Risks, which we hope our risk owners shall read

O is for Objectives, though our projects sometimes have none

J is for Jargon – you’ll agree our profession has some!

E is for Effort estimates, which can make sponsors cry

C is for Communication, which can be hard if you are shy, and

T is for Teams, which we strive hard to build

M is for Milestones, on schedules they look like diamonds in the rough

A is for Assumptions, of which we never log enough

N is for Negotiate, which we have do each day

A is for Authority, which we’d have if we had our say

G is for Gantt, we secretely love his charts

E is for Emotional Intelligence, with which we hope to win stakeholders’ hearts

M is for Monte Carlo, where some day our luck we want to try

E is for Earned Value, which we’d all like to apply

N is for Network diagrams,  which we don’t like to draw, and

T is for Templates, which our PMOs insist we use, because they lay down the project management law!

I is for Issues, projects have those, never doubt, and

S is for Schedule, which newbies think project management is all about!

F is for Float, which is good for your schedule AND your boat

U is for Unanimous agreement from key decision makers, which our decisions need to pass, and

N is for Near-critical path activities which (if we ignore them) can bite us in the ***

(Note: this article was originally written and published by me in July 2013 on my personal blog, kbondale.wordpress.com)

An agile project management office might sound to some like an oxymoron, right?

This might be a reasonable assertion as many PMOs were first formed to provide oversight over a portfolio of projects and enforcing standards sounds like the antithesis to agility. But many successful PMOs have evolved beyond governance and control to helping their company reach higher levels of organizational project management maturity, and increasing agility should be complementary and not contradictory to this pursuit.

There are many ways in which PMOs can hamper progress towards greater agility including:

• Enforcing standards over principles
• Continuing to apply traditional funding models and prerequisites to agile investments
• Obsessing over vanity metrics such as velocity or time to market rather than business value delivered or shipped features utilized
• Evangelizing agile from the ivory tower instead of actively engaging with and supporting teams
• Failing to inspect and adapt

So what can a PMO do to actively support an agile transformation?

• Collecting chronic impediments from agile teams, curating and prioritizing them, and championing their elimination by the appropriate senior leaders
• Having the courage to say "NO!" when a given context is not suitable for using an adaptive approach
• Advocating for funding to incent early adopters to try new delivery approaches
• Encouraging staff who possess the right expertise, behaviors and attitude to train and take on Agile Lead/Scrum Master or Product Owner roles with coaching support
• Examining their own operational processes and leaning them out as much as possible
• Shifting portfolio reporting from being a manual, onerous process to the automated consumption of information radiators
• Migrating from an artifact-centric delivery approach to an information-centric model
• Transforming heavy, gate-based governance to a metrics-driven, exception-based process
• Working actively with functional managers, procurement, HR and other key stakeholders to change their project engagement models to be more support of adaptive approaches
• Helping portfolio governance committees to make their investment selection, evaluation and prioritization processes more agile

An agile transformation provides the leadership of a PMO with a good opportunity to review their charter and service catalog - are these still relevant, and if not, what can be changed to ensure that the PMO is not identified as common impediment by agile teams!

It can be a significant step towards improving project management capabilities when a company decides to move from storing project information in an inconsistent fashion across multiple files, databases and templates to capturing this information within a consolidated project management information system (PMIS).

By taking this step, they position themselves to reap multiple benefits including reducing the effort involved in reporting project status at the portfolio level, providing a consolidated view into staff utilization and available capacity, and simplifying the process of accessing historical project information to serve the needs of future projects.

However, as with the implementation of any new technology, behavior changes is required to achieve these benefits.

If there is no change in the quality, accuracy, timeliness or completeness of the data being captured, the outcome is actually worse than if no solution had been implemented.  While the lack of easy access to project information in the past would have prompted concerned executives to seek out project managers to get live updates on project status, once a significant amount of effort and cost has been spent in implementing a PMIS, they will want to see some return on that investment and will be likely to use it as the official source of project knowledge.  If the data within the PMIS is not complete or accurate, there will either be a loss of credibility in the tool or even worse, poor decisions might be made based on bad data.

So what are some tell-tale signs that your PMIS is ailing?

• If a view of staff utilization shows that most people are over-allocated to an unnatural extent (i.e. more than 150% allocation on a weekly basis) or don’t appear to be allocated to anything
• If project status updates on active projects are missing or are more than a couple of weeks old
• If a spot check of the schedules for key projects reveals multiple tasks whose planned start or end dates have passed without any progress reported against them
• If risk registers or issue logs are overflowing with generic or low severity items and finding a key issue or risk is harder than a needle in a haystack
• If projects are shown as being active which are known to have been completed or cancelled and/or no data exists for projects which are known to be active

So what might be the cause of some of these symptoms?

Sometimes, it might be that executives and key stakeholders have never used the PMIS as their source of project information or staff utilization.  If that is the case, then it’s no surprise that project managers or team members may be unwilling to invest the time to keep the PMIS up to date. 

Other times, it might be a training or coaching issue – if no one is regularly keeping an eye on the data and following up on compliance or quality issues it’s no surprise that it will get stale. 

Another cause might be that the system or procedures are too onerous or time consuming to use – this points to the lack of an effective feedback loop with end users which could have resulted in fine-tuning or improvements to the system. 

The source of most of these issues is a lack of good change management practices.

A PMIS can improve the productivity of your project teams, but remember that a pile of garbage in a colorful bag with a decorative bow is still just as smelly!

(Note: this article was originally written and published by me in July 2013 on my personal blog, kbondale.wordpress.com)