Easy in theory, difficult in practice

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

About this Blog


Recent Posts

Evaluate your ceremonies with a W5 check

How lean is your project management style?

Breaking habits requires substituting one routine for another

Identifying and taming “800-pound gorilla” projects

How do you know when your agile ceremonies are Done?

Seven deadly sins of scheduling

Categories: Project Management, Tools

Something I’ve taken for granted is a project manager’s ability to create and maintain a project schedule.  The reality is that most accidental project managers spend at least as much time struggling with their schedules as they do getting real value out of them.

No project scheduling tool is inherently bad, but there are a few cardinal sins that will reduce the value you achieve by using these indispensable aids.

1. Use a scheduling tool to help you define the scope for your project. Most scheduling tools are good for entry of tasks with durations and dependencies but are lousy as brainstorming or iterative definition aids.  Spend the time to create a Work Breakdown Structure (WBS).  Then using traditional Post-It notes or a similar visual approach, sequence the activities that will deliver the scope of your project.  Once you’ve got the skeleton ready, you are ready to transition this information to a scheduling tool.  Otherwise, get ready for spaghetti-like dependencies that are impossible to trace…

2. Use scheduling constraints excessively. Too often, I’ve reviewed project schedules that are saturated with constraints – these have been used as a cheap way of getting tasks to start and end on specific dates.  While this may help to get a quick & dirty view of a project’s time-line, it effectively neuters a critical path methodology-based scheduling engine and eliminates the ability to optimize schedules through appropriate use of slack.  Constraints should be used to capture real world situations only (e.g. we can’t start this task until the next Saturday as that happens to be the first available maintenance window).

3. Use automated resource leveling and effort-driven tasks. Automated resource leveling is a great concept but is poorly used – unless you are 100% certain about the relative priority of individual tasks (most organizations can’t even figure out the relative priority of their individual projects!), this feature can effectively shred your schedule.  Effort-driven tasks work well for projects where there is a true linear relationship between resource allocation and task duration – however, on most knowledge-based projects, Brooks’ Law and the old cliché about nine women being unable to have a baby in one month come into play.

4. Capture too many (or too few) tasks. Remember that a schedule is just a model of what you expect to happen that serves the dual purpose of being a forecasting and tracking tool as well as a communication medium to team members and project stakeholders.  There is equally as much pain of having a schedule that is at too high a level of detail (it is too easy to lose track of schedule progress) as there is of attempting to define and track every minuscule activity that occurs on the project (you’ll spend all your time maintaining the schedule).

5. The schedule is out of date the moment it is updated, so why bother updating it? Of course, this is a relative state, and yet many PMs seem to feel that keeping a schedule current is a waste of time.  Unfortunately, this reduces the value of a schedule to purely being a task list.

6. Outline levels and milestones are GREAT! Outline levels and milestones are a good way to present schedule information in a fashion that will satisfy multiple levels of detail for status reporting.  Having said that, too much of a good thing is also not a great idea – just because your scheduling tool supports hundreds of outline levels or milestones per schedule does not mean you have to push the boundaries of these limits!

7. We can’t start over… The worst sin of scheduling is to work with a schedule that has reached such a level of chaos that no one derives any value from its continued existence.  Many project teams take that undesirable journey to Abilene without someone stepping back and saying “let’s start over” – not only can that reduce administrative effort but it can create the perception of a clean slate for the project team.  To quote Kenny Rogers, “You got to know when to hold ’em, know when to fold ’em…

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

Posted on: February 23, 2018 07:29 AM | Permalink | Comments (17)

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 (9)

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)

"I went into a McDonald's yesterday and said, 'I'd like some fries.' The girl at the counter said, 'Would you like some fries with that?' "

- Jay Leno