Skip to main content

Author: Kiron Bondale

Governance for IT Work Intake – One Size Definitely Doesn’t Fit All!

When organizations decide to adopt project portfolio management practices within IT, the usual starting point is to revamp their work intake and authorization processes by incorporating the active involvement of one or more cross-functional external (to IT) governance committees.  The expected benefits of this change include a reduction in stealth work as well as a gradual evolution in the IT engagement model.

When designing the changes to these processes, a common challenge is finding the right balance between too much involvement of external governance bodies and too little.   Even if governance committee members are available, excessive involvement may be perceived as IT abdicating its responsibilities.  With insufficient involvement, IT resources would continue to be diverted from the highest organization value initiatives.

One way to reduce the risk of this happening is to define the scope of external governance over different types of IT work.  Almost all IT work can be classified as one of the following:

  • Large projects
  • Service requests/small projects
  • Operations(”Keep the lights running”)

Objective definitions for each of these categories should be developed to facilitate the consistent differentiation between large & small projects.  These definitions should ideally include multiple criteria – for example, a combination of estimated cost and planned effort.

For large projects, selection and prioritization decisions should be the responsibility of the governance committee.  Sufficient project status details should be provided to the governance committee as part of their regular reviews of the active project portfolio to facilitate decision making.

For service requests or small projects, work authorization and prioritization should be done by the IT management team, but the aggregate annual or quarterly resource effort and costs for such work should be pre-approved by the governance committee and aggregate actuals should be reported on a regular basis.  This will ensure that strategic projects do not suffer the “death by a thousand cuts” that can result from too many service requests being delivered.

For operations activity, work authorization is performed by the individual IT line managers, but the total costs and resource effort should be budgeted annually and actual cost reported to governance committees on a regular basis.

Providing governance committees with consistent visibility across project and operational work should improve balanced decision making without over utilizing their limited capacity.  In essence, this approach embodies a core objective of project portfolio management: optimizing the return on limited (governance) resources!

Don’t forget to leave your comments below.

 

Knowledge-based PM Certifications: Value Add or Necessary Evil?

PMO Leaders, Project Managers, Stakeholders, lend me your ears; I come to neither bury knowledge-based certifications, nor to praise them!

There are two broad types of project management certification approaches – purely knowledge-based or those that incorporate experience-based evaluation. 

PMI uses both approaches – the PMP certification uses a predominantly knowledge-based approach while the PgMP certification uses a balance of knowledge and experience-based methods. Although PMI’s PMP certification is the global de facto standard, other project management associations also offer knowledge-based certifications. 

I previously wrote in “The dualism of the PMP credential and challenges with any knowledge-based certification”  about the limitations of a knowledge-based certification and didn’t want to recycle that content.  However, a very common question in LinkedIn’s Project Management Q&A category is “Should I get my XYZ PM certification?”, so I felt that there might be some value in assessing the most common justifications.

Fact

1. It’s a hiring prerequisite – right or wrong, in many companies, hiring managers or recruiters will only look at your resume if you have a certification.  While this might not be the only method of evaluating someone’s suitability, it is a filter that simplifies the workload for these gatekeepers. 

2. You might be paid more – according to the Sixth Edition of the PMI Salary Survey, it could increase your salary by up to 10%, either through a change in role, base compensation or bonus.  This will obviously be influenced by factors including local supply and demand for project management skills and geographic differences. 

3. It’ll improve project management consistency – certifications provide a common lexicon so long as your organization’s methodology and its practitioners use a single association’s body of knowledge.

4. You might gain some project management technical knowledge which you didn’t possess before – given the comprehensive nature of most PM bodies of knowledge, even experienced PMs are likely to learn something new by studying for a certification exam.

Fiction

“It’ll make you a better PM – as the majority of the issues I listed in “Seven Deadly Project Manager Sins illustrate, the differences between a “good” and a “bad” PM often relate to their ability to appropriately apply soft skills and no knowledge-based certification can assess this.

2. It’s the best way to learn about project management – While attending a certification prep course or reading certification study aids might increase your knowledge, a foundation project management course, managing real projects or being mentored are more cost effective means of gaining the same knowledge.  A common recommendation I’ve made to PMs is to read their association’s monthly journal cover-to-cover each month and then to assess their knowledge of the profession at the end of the year.

3. It will differentiate you from others – the ubiquity of the PMP certification has mostly marginalized this benefit.  Specialized or esoteric project management certifications may still provide this benefit. 

While this article is not written to make you avoid knowledge-based project management certifications, hopefully it has helped with the decision-making process.

Don’t forget to leave your comments below.

 

 

Program Management – the Missing Link Between PPM and PM

Organizations that have achieved consistency with their project management practices or have mastered “doing projects right” might launch Project Portfolio Management (PPM) initiatives to attempt to “do the right projects” by improving the alignment of their enterprise portfolio with the organization’s vision and purpose. 

Governance committees get formed and effort is expended in defining and implementing processes for project selection, evaluation and prioritization as well as ongoing portfolio monitoring and balancing.  However, momentum and enthusiasm wanes once the governance bodies experience the level of complexity and effort involved in trying to evaluate and prioritize hundreds (if not thousands) of projects.  Soon, evaluation and prioritization practices are branded as “academic” and the organization reverts to its previous subjective politically or emotionally-driven approaches.

I highlighted this issue in my earlier article, Applying Consumer Marketing to Project Prioritization, as being a barrier to achieving PPM success, but did not position the valuable role that Program Management plays in helping to resolve it.

Vaughan Merlyn wrote in his article Portfolio Management: So Much More than a Collection of Projects! that Program Management can build the bridge between high-level purpose and project proliferation. 

However, to achieve this benefit, programs need to be recognized as being something more than just a set of interdependent projects.  Projects deliver outputs but programs must be able to generate meaningful business outcomes

The benefits of this approach seem logical – a governance committee should be more capable of selecting and prioritizing a small, manageable set of programs as program evaluation criteria will likely focus on true business value.  The same cannot be said for projects – while some might produce outputs that will generate real value to an organization or its customers, many only produce deliverables that are inputs to be consumed by other projects or internal processes. 

For Program Management to be successful, the role of the Program Manager needs to mature beyond the traditional project coordination and integration activities to include identification, evaluation, selection and prioritization of projects.

Program Managers must possess an understanding of the business processes and specific key organization performance indicators related to their program domain and should use these as the core driver in their decision making. 

One of the reasons that project managers struggle when they are promoted to Program Management roles is that while they were used to focusing on winning battles, Program Managers need to focus on winning a war, which means knowing which battles to fight and which to avoid.

Using the analogy of financial portfolio management, an investor can be profitable by directly trading in individual securities, but as one’s investment portfolio grows, the ability to remain well informed of research and fundamentals that guide decision-making becomes progressively harder.  This challenge has been the raison d’être for mutual funds, and the same rationale could be applied to Program Management. 

PPM can succeed without Program Management, but as the enterprise portfolio grows, the bridging benefits Program Management provides will more than justify its costs.

Don’t forget to leave your comments below.

Seven Deadly Project Manager Sins

In spite of an increased focus on competency in PM conferences, journals and online knowledge sources, organizations continue to experience project failures at the hands of incapable PMs.  

Identifying common negative behaviors that can contribute to these failures might be the first step towards recovery:

1. Communication imbalance – communication consumes a significant percentage of a PM’s time so one would assume that this is a competency that even poor PMs would excel at.  Unfortunately, some PMs treat knowledge & information like power – sharing it with those they wish to curry favor with, and leaving everyone else in the dark.  Other PMs have a case of verbal “Montezuma’s revenge” – this is equally bad as stakeholders are unsure what information is critical and what is minutiae.  I covered this issue more extensively in the article “A dripping faucet or a fire hose – which most resembles YOUR project communication strategy?”

2. Neglecting stakeholders – As I wrote in “Don’t get blindsided by stakeholder influence” , PMs can get tunnel-vision by focusing purely on their direct customer or sponsor.  While this individual might be the one signing deliverable acceptance forms and evaluating your performance, a good PM needs to practice 360 degree management – sponsor, stakeholders & team. 

 3. Inaccurate or incomplete project control books – It doesn’t matter how heavy or light your PM methodology is (or even if you organization doesn’t have one).  There’s a basic set of project data that should be kept current so to facilitate project tracking, control, monitoring and (if you win the lottery) transition.  Having an out-of-date schedule is worse than having no schedule at all – at least a stakeholder doesn’t draw any wrong conclusions from a non-existent schedule.

 4. Ignoring conflict – Conflict is a natural occurrence on most projects but accidental PMs are often unused to managing interpersonal conflicts and might be tempted to ignore them in the hopes that the situation will resolve itself.

 5. Jettisoning risk management – If a PM happens to be aware of good project management risk practices, they might not have the intestinal fortitude to “sell” the necessity for these practices to their sponsor, stakeholders or team.  Under pressure to deliver, if they skip risk management, they’ll at least have the opportunity to improve their fire-fighting skills!

 6. A blind focus on the triple constraint – While scope, schedule & cost constraints are important, a PM might ignore the fact that a project has to deliver business value to avoid “the operation was a success, but the patient died” syndrome.  Poor PMs are less likely to ask questions such as “Is this deliverable necessary to the end result”, “Are we gold-plating” or “Is this project still of value to the organization”?

 7. Poor assumptions management – Projects possess uncertainty and to try to reduce this uncertainty, we make assumptions.  A good PM will log critical assumptions, share them with the overall project team, attempt to validate them proactively, and use them as one of the inputs into risk identification.  A bad PM will forget the assumptions shortly after they were made…

By no means is this list exhaustive, so I’d encourage you to contribute some of your own in comments.  Hopefully, we can distill a comprehensive set of cardinal sins to eliminate that justification for bad PMs: “I didn’t know!”

Don’t forget to leave your comments below.

Technical Competency for Project Managers – Valuable Asset or Source of Risk?

A question that is frequently asked in online project management communities is “How critical or valuable is it for a project manager to have detailed subject matter expertise or technical competence related to the scope of their projects?”. 

To clarify, I am not referring to business or process knowledge – I believe that a PM has to have a good understanding about how the deliverables of their projects will be used and they should have sufficient process awareness to help identify the project and business risks that may reduce benefits realization upon project completion.

Here are a few of the obvious benefits to having “hands on” knowledge and experience.

  1. The ability to help with brainstorming possible solutions to issues as well as the ability to contribute more extensively to risk identification, analysis and response
  2. When the team gets into a crunch, the ability to “pitch in” and keep the schedule on track.
  3. Better ability to validate effort estimates from the team
  4. It can ease the process of earning respect from team members
  5. Avoiding the risks related to “I don’t know what I don’t know”

However soft skills don’t usually increase from having technical competence, and yet, these soft skills are often the biggest source of challenge for PMs.

Beyond this concern, there are other risks to be aware of:

  1. We often default to giving higher priority to those tasks that we are most comfortable with – especially when we are under stress.  For a novice PM, this could mean focusing on “hands on” technical work and neglecting core PM activities.
  2. Whereas a PM with limited technical experience is likely to seek knowledge from subject matter experts, a technically competent PM might simply make an assumption based on past experience – since no two projects are the same, what was applicable in one situation may not be applicable in another.  In addition, unless the PM is making an effort to remain technically “current”, their knowledge might be obsolete which increases the potential for poor decision making.
  3. There is an increased likelihood of deliverables micro-management or for technical “head-butting” with team members.

With constraints forcing organizations to “cut corners” when staffing project teams, a PM is often expected to perform multiple roles.  While this approach can increase the value the PM brings to the organization and is one way of introducing someone to their first PM role, it presents risks that a PM should be aware of and should manage through consistency and self-awareness.

Don’t forget to leave your comments below