Easy in theory, difficult in practice

My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

When is it not a good idea to launch a project?

Avoiding groupthink on long-lived teams

Be careful which project constraint you measure, as you just might get it!

What do I look for when reviewing resumes for project manager positions?

RBS is one more technique for your estimation tool belt!

When is it not a good idea to launch a project?

Projects get started for a variety of reasons but good intentions are usually not enough to justify investment. In spite of defining or enforcing intake criteria, projects continue to be launched which should never have left the dry dock.

What are some of the warning signs to look out for?

No one appears to be able to answer the question Why?

I’m not asking for a detailed scope definition or “to be” process map. All I am looking for is someone who is able to paint the picture as to how the world will be better if this project gets completed. Without this, the likelihood of significant effort being invested in a snipe hunt increases.

Sometimes the initial answer to why we are doing a project is superficial – in such cases, you could use 5 Whys to try to identify the real reason. If it turns out that it’s just to build someone’s empire or stroke someone’s ego, back away slowly…

Too many throats to choke

While it might take a whole village to raise a (project) child, diffused accountability translates to weak governance which results in ineffective decision making. If there isn’t a clear understanding before the project starts as to where the buck stops, keep looking.

Too many external dependencies

Every dependency can be a source of risk. The more a project will rely on all the stars aligning perfectly, the less likely it is to succeed. If there isn’t an easy way to reduce the number of external dependencies, is it still worth proceeding?

There’s too much going on

If the sponsor, key stakeholders or core team members are distracted with multiple other bright, shiny objects, how much are they likely to focus on your project, and what will be the quality of the decisions and deliverables produced? Unless you are confident that this project can bubble up to the top of their priorities (and stay there), maybe it’s better to wait until they can focus.

It doesn’t align with the company’s risk appetite

Organizational risk appetites can evolve, but that shouldn’t be because someone has decided to bet the farm on a “sure thing”. Too big to fail just means we haven’t been hit by a big enough asteroid yet!

There’s no risk in delay

Is it important but not urgent? What’s the worst that could happen to the company if the project was delayed by a year? If there isn’t a compelling reason to launch the project now, there might be some other more urgent initiatives which could use the resources.

Have we tried (and failed) before?

Sometimes organizations learn from past stumbles and are able to succeed on future attempts – those are the exception, not the rule. Without fundamental changes in underlying conditions, capabilities and expectations, there’s a strong likelihood of repeat failure.

If your project breaks one or more of these rules, how confident are you that you will avoid realizing the risks posed?

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

Posted on: February 22, 2018 07:29 AM | Permalink | Comments (7)

Avoiding groupthink on long-lived teams

Categories: Agile, Project Management

Long-lived teams are often presented as being superior to their temporary counterparts. The benefits of longevity include the avoidance of wasteful forming-storming-norming cycles, higher levels of trust and psychological safety within the team and a more accurate understanding of what someone means when they communicate with us.

But there is a potential downside to persistent teams which can erode many of these benefits: groupthink.

Groupthink usually refers to a situation where team members prioritize consensus over the quality of a given decision or outcome. We might all disagree with Bob’s recommendation on how to address a project issue, but we value the harmony of the group over the mediocrity of his approach and hence we don’t challenge it. 

According to Irving Janis, the social psychologist who is credited with introducing the term, groupthink tends to occur most often where there are high degrees of cohesiveness, external threats, difficult decisions or isolation of the team from others. These factors are often found on long-lived teams.

So how can we avoid groupthink on long-lived teams?

One countermeasure might be to use Delphi or a similar method of anonymously or simultaneously gathering input from the team. This will reduce the likelihood of any one team member winning a “first to speak” advantage and will provide a structured approach to surface and discuss differing viewpoints.

Another option is to have the group nominate one team member to act as a devil’s advocate. This selection should be made on a per decision basis. Since everyone knows that this team member is responsible for finding weaknesses within a decision it eliminates their fear of being perceived as disruptive. Care needs to be taken in selecting the right team member to play this role. Someone who is likely to have significant interest in the outcomes of a decision might not be the best candidate as they might consciously or unconsciously disqualify the group’s approach to further their own path of action.

Have the foresight to bring someone in from the outside who has no stake in the outcome. This approach can replace the previous suggestion if team members feel that none of them can impartially play the role of devil’s advocate. This method has its own challenges as it might take some effort for the outsider to gain sufficient context to be an effective contributor to the decision.

Finally, breaking the team into two independent groups and having each group develop a recommendation is a very explicit method of eliminating groupthink. Of course, this requires a team which is large enough that such a sub-division is possible. If this approach is used more than once, it is a good idea to have different people in each group for each distinct decision.

When all think alike, the no one is thinking – Walter Lippman

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

Posted on: February 21, 2018 08:29 AM | Permalink | Comments (8)

Be careful which project constraint you measure, as you just might get it!

It is a commonly held belief that in the absence of a higher driving need, people will focus on those activities or behaviors for which they are being measured and subsequently either positively or negatively reinforced.

Given this premise, it should be no great revelation to leadership teams that if a balanced approach is taken by governance bodies to project oversight, this should result in a correspondingly greater incentive for project teams to consistently perform practices across all key project management knowledge areas.

This is why it never ceases to amaze me that the same senior stakeholders who complain about the lack of practice consistency across their project teams with regards to certain knowledge areas are equally guilty of forcing these same teams to focus on one or two specific constraints.

Please note that I’m not referring to the practice of communicating the priority of project constraints as it relates to the business objectives or key drivers for a project. That is an essential activity which will ensure that project and governance teams make the right types of trade-off decisions. For example, if a particular project is addressing a time-sensitive regulatory requirement, schedule is the primary driver and it is perfectly reasonable for the project team to propose decision recommendations which will protect project deadlines at the cost of other constraints such as scope or cost.

However, should an organization focus exclusively on one or two constraints across all projects in the portfolio, this can result in a culture which colors not only team decision making, but also the degree to which they comply with the company’s project management methodology. While you might feel that a safety measure to guard against this outcome is regular project assurance reviews or audits, non-compliance findings which are unrelated to the supreme constraint are likely to be marginalized.

A common example of this behavior occurs in companies which are under sustained financial pressure or scrutiny. The last decade has not been kind to both public and private sectors, hence it is little surprise that cost is king. You might feel that regulatory projects or product development projects would give time a higher priority, but even on those, it is rare to see governance oversight bestowing financial carte blanche on teams just to hit a date. Budgeting, financial tracking and reporting are usually performed quite diligently as there is significant oversight in that area, but the same is usually not observed across the remaining knowledge areas.

While you might feel that this neglect may apply to practices such as risk or quality management, it might even be identified on the stereotypical project management practices of time or scope management. This is certainly not to say that teams are ignoring milestone delivery dates or customer requirements. Results are still being produced but they might not be delivered following consistent practices.

If you are still skeptical, do a spot check on your own project portfolio:

  1. Identify a sample subset of your active projects which is representative of the overall portfolio in terms of strategic alignment, drivers, and functional representation.
  2. For each of these identified projects, check for the existence of a critical (as per your methodology) artifact which supports each project management knowledge areas. For example, for scope you could look for a work breakdown structure or other type of scope decomposition document. For stakeholder management, check whether there is a detailed, up-to-date stakeholder analysis register.
  3. Review each artifact you are able to locate for both quality and currency of data. You could use a very simple rating as follows:
    • Up-to-date, high-quality content
    • Somewhat out-of-date, or somewhat inaccurate content
    • Completely out-of-date, totally inaccurate, or missing
  4. Once this has been done for all projects and all knowledge areas, analyze the results for a pattern of diligence in one area and poor compliance in others.

If you have identified that there does seem to be an unhealthy focus on one constraint, you will likely want to review the implications of this with your senior management team. If nothing else this gives you the opportunity to conduct a leadership gut check to help you determine whether there is real commitment to establish or improve organizational project management capability.

This might also provide you with a good coaching moment to debunk the myopic view that one can safely neglect certain project management practices without causing an impact to the chosen ones – as we all know, there is a very tight dependency between all knowledge areas.

W. Edwards Deming is often erroneously quoted as having said, "You can't manage what you can't measure." In fact, he stated that a cardinal sin was trying to run a company based solely on reported measurements. The same could be said of an excessive organizational focus on one constraint.

(Note: this article was originally written and published by me in December 2013 on Projecttimes.com)

Posted on: February 20, 2018 07:54 AM | Permalink | Comments (8)

What do I look for when reviewing resumes for project manager positions?

It would be wonderful if there was a foolproof method of assessing the merits of a candidate when hiring a project manager and perhaps with the advances in machine learning this may be possible at some point.

Until then, hiring managers face significant challenges when filling such roles – the combination of life experience, hard and soft competencies as well as personality and cultural fit which will identify the perfect candidate are not as easy to assess as a technical skill such as the ability to develop quality code in a given computer programming language. 

To further complicate matters, in most North America cities the number of applications for a position is likely to run into the hundreds if not thousands.  This volume is partially due to the success which PMI and other project management associations have achieved in marketing the career benefits of the profession.

So what can one look for to improve the effectiveness of the initial resume short-listing process?

Spelling and grammar – communication skills are critical to the role of a project manager but insufficient attention to detail when preparing something as important as a job application poses a greater concern that key project management artifacts might not be produced or reviewed with appropriate professionalism or diligence.  This is especially important in companies which are at a low-level of organizational project management maturity as it takes a lot of effort to gain credibility in the profession, and just one spelling mistake identified by the wrong executive to lose it.

A healthy balance between education and experience – unless the vacancy is for a contract role, I want to know that the individual has invested in themselves to gain some education to complement what they’ve gained through practical experience.  While most hiring managers may focus on the latter, without a good foundation of project management theory (e.g. understanding the “why” behind the “what” of project management practices) you may end up with someone who is not as adaptable or resilient when faced with a situation they’ve never encountered before.

A custom cover letter – when I see a generic cover letter that lacks relevancy to the company, project or role, I am concerned that the same superficial approach may be used when addressing the information needs of different stakeholders or worse, the individual might take a one size fits all approach to project management practices.

A focus on business outcomes – candidates will often list metrics such as duration, budget or peak team size for a sample of the projects they’ve managed.  Don’t get me wrong – this is good information as someone who has never managed a project with more than five team members may not be able to successfully handle a project with a hundred staff.  However, I am also looking for recognition of what was achieved through their projects as it will give me some confidence that the candidate is able to think beyond the triple constraint.

There are no guarantees of success when recruiting project managers, but with techniques such as the ones I’ve provided above it should be possible to identify a good set of candidates to progress to the next stage of the hiring process.

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

Posted on: February 19, 2018 09:56 AM | Permalink | Comments (21)

RBS is one more technique for your estimation tool belt!

Categories: Agile, Project Management

Project managers need to be comfortable with different estimation techniques. Foundational project management courses will teach you about analogous, bottom-up, parametric and three-point estimating. Take a course covering agile delivery and you'll learn about relative sizing techniques such as estimating poker or t-shirt sizing.

But have you heard of RBS?

I'm not referring to a Risk Breakdown Structure, a Resource Breakdown Structure (seriously, couldn't they have found a different name for one or the other to avoid creating confusion about which RBS is being referred to?) or any other type of breakdown structure, but rather Randomized Branch Sampling.

This technique was originally proposed by Raymond Jessen in 1955 for the agriculture industry as a method of estimating how much fruit would be found on a given tree (hence the significance of the word "branch"). This approach has been adapted by Dimitar Bakardzhiev for use on software projects following an agile delivery approach and could be similarly adapted for a traditional, deterministic project where a WBS has been created.

I would encourage my blog followers to read Dimitar's article but here is an overview of the process once you have decomposed your project to an appropriate level of details (e.g. epics & stories or control accounts & work packages).

  1. Make a note of how many epics or control account have been identified. Let's call this "M".
  2. Randomly pick one of the epics or control accounts.
  3. Make a note of how many stories or work packages are associated with that epic or control account. Let's call this "N".
  4. Randomly select one of those stories or work packages.
  5. Estimate the size or effort of that story or work package. Let's call this "X".
  6. Calculate the overall size or effort of the project or release using the formula X/(1/M * 1/N)
  7. Do steps 2-6 between 7 to a dozen times. This will provide you with a probability distribution for your project's total size or effort as well as an average or mean which you could use for your estimate.

This approach does require that your project is large enough to have at least a dozen epics or control accounts and does assume that the decomposition is clear and complete.

While you might be comfortable with tried and true estimation methods it's a good idea to use more than one estimating method. Certain techniques are appropriate at specific points in time over the life of your project based on stakeholder needs and the level of uncertainty remaining. There's also the benefit of being able to sanity check estimates when multiple approaches get used.

Learning new techniques such as RBS can help us become more effective project managers but only if we understand when and how to use them as well as their limits.

"A Fool with a Tool is still a Fool"


Posted on: February 18, 2018 07:54 AM | Permalink | Comments (15)

"Peace comes from within. Do not seek it without."

- Buddha