Easy in theory, difficult in practice

by
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

RSS

Recent Posts

How do you engage remote team members?

Seven deadly sins of scheduling

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!

How do you engage remote team members?

Categories: Project Management, Risk Management, Team Building

No question, there are many benefits to being collocated with your full team when managing a challenging project.

But organizations are looking to reduce real estate costs, provide their employees with the benefits of telecommuting, and take advantage of a twenty-four hour work day by having teams strategically split across multiple time zones. So if we accept the inevitability that we might have to manage a project with some remote team members, how do we reduce the likelihood of this impacting team effectiveness?

Herding cats is hard enough in person – it’s impossible to do when team members are scattered geographically. If they don’t buy into the vision of the project, you’ll face an uphill battle to get them aligned. If the project is a mixed blessing – hurting some team members while it helps others, you might need to spend more face time with the team members who will be impacted the worst.

It is critical to fight tooth and nail to hold a project kickoff meeting which all team members and key stakeholders can attend in person to give you and your sponsor the best shot at inspiring them. But just because your team members are aligned at the beginning doesn’t mean drift won’t happen for a variety of reasons – perhaps they aren’t seeing sufficient progress or maybe a sexy new project is competing for their attention. So use your regular team meetings as an opportunity to re-engage them.

“Out of sight, out of mind” is very real.

It can get easy to neglect remote team members when it comes to recognition and team building, especially if the majority of your team members are collocated with you. Add a simple team building activity at regular intervals to your team meetings – there are many available via a simple Internet search which lend themselves to remote delivery. Even better, make this a rotating responsibility to give each of your team members a chance to be the life of the party.

It can be tempting to impose the need for frequent progress updates or status meetings to reduce your fears, but this will become a self-fulfilling prophecy as your team members become disengaged or irritated with being micro-managed. You would be better served having a frank conversation with your team – help them understand your responsibilities and engage them in developing a reporting process which still meet your needs while empowering them.

Trust your team members to behave like professionals and don’t give them a reason not to.

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

Posted on: February 24, 2018 09:51 AM | Permalink | Comments (3)

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

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

Categories: Project Management, Project Portfolio Management

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!

Categories: Project Management, Project Portfolio Management

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)
ADVERTISEMENTS

"A closed mind is like a closed book; just a block of wood."

- Chinese Proverb