Easy in theory, difficult in practice

Organizational change management (OCM), while not a new discipline, is receiving more air time than it used to when the focus used to be on “just do it”.  Whether this is the outcome of well publicized changes which didn’t get implemented as well as planned, brainwashing by consulting firms, or an evolution in thinking on the part of leadership teams, it is a positive step.

So what does this mean for a project manager?

In most organizations, the project manager’s role begin once some financial justification has been provided to initiate a change and will end once the deliverables required to implement the change have been completed and transitioned to operational team.  Viewed through that lens, a project manager might feel that OCM takes place before and after their involvement.

While this is partially true, it doesn’t mean that a project manager can’t take a leadership role in setting the organization up for change success.

Here are a few of the ways in which this can happen:

• Reminding the change leadership team of the importance of an easy-to-understand end state.  Change champions might have a crystal clear vision of what they are trying to accomplish, but if that same vision is not consistently shared by those expected to adopt and sustain the change, it will become very difficult to get commitment and alignment towards the same goals.  Through regular stakeholder analysis, a project manager can identify gaps in understanding and buy-in and can help to focus communication efforts from the change leadership team.
• Ensuring that adoption and sustainment deliverables are not given a lower priority.  If the project falls behind schedule or runs over budget, it might be tempting to cut back on the scope on key OCM work packages.  In such cases, the project manager should engage appropriate stakeholders to identify and quantify the risks of such short cuts to avoid the “operation was a success but the patient died” syndrome.
• Helping the change lead develop a detailed plan for delivering OCM work packages.  While a high-level change plan should exist in advance of the project’s initiation, that will not be at the right level of detail to identify timing risks with key communication or procedural deliverables.
• Ensuring an appropriate level of involvement by those affected by the change in key activities.  Whether it is in requirements elicitation, user interface prototyping, desk-level procedures development, or communication messaging, active participation from those who are expected to adopt the change is a recognized good practice but may not be given the attention it needs due to competing operational or project priorities.  The project manager can help to reinforce the importance of this involvement and should escalate through their defined governance escalation path if end users are not being engaged at expected levels.

Project managers are expected to go beyond just meeting the triple constraint by helping the business to realize the expected outcomes of the investments made in projects.  Active involvement and support for sustainable organizational change practices is one path for them to meet those expectations.

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

A past article I'd written covered the importance of preparing your team members to tackle a new project.

But what happens when a new team member joins in the middle of the project?

Onboarding is the complete set of activities which get performed when someone joins a company – providing their system access, finding them somewhere to sit, introducing them to their co-workers and so on. But onboarding is also crucial when an existing employee joins a new project – without this they are likely to feel disconnected from the rest of the team, and may not commit themselves fully to the project’s success.

Is this really necessary? After all, the new team member has likely worked for the company for a while, already has an assigned workstation, knows his or her co-workers and will probably understand what’s expected of them.

That may all be true, but a specific project’s team culture can be quite different from the culture of the department or organization as a whole. While the new team member may have worked on projects before, the specific practices which your team is using may be different from what they were used to before. They may not know all the other team members, especially if it is a cross-departmental project.

So what are some steps to properly onboard a new team member?

Prepare for their arrival. Just as you would want to ensure that a new employee’s workstation, computer, phone and e-mail access and even business cards are ready before their first day, make the new team member feel that their joining was not a surprise by informing the rest of the team of the new arrival in advance, finding a spot for them to work and confirming their access to project documentation and other applications.

Introduce them to your sponsor and all of the team. This seems like a small thing, but if they have never worked on a project for your sponsor before, establishing that connection will likely make the new team member feel that their contribution is valued. While they may not work directly with the full team, they will be equal custodians for the team’s ownership of its practices and work products so it is important for them to know and be known by all.

Hold a mini-kickoff meeting welcoming them to the project. While the primary audience will be your new team member, you should use it as an opportunity to do some team building, to reinforce key messages about the project’s vision and remind the whole team how important everyone’s work is to achieving that vision. Have your existing team members share some of the key rituals which are part of the team’s culture.

Find them a project buddy. Whether it’s one of the existing team members they will be working closely with, or someone leading a different work stream, identify a willing “go to” person who will help support them in their first couple of weeks. This is a great way to make the whole team responsible for supporting one another, and will reduce the draws on your time.

You’ll never get a second chance to make a good first impression, so onboard new team members with the same thoughtfulness as you’d show to a new employee!

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

The Book of Revelation describes the Four Horsemen of the Apocalypse who, based on a common interpretation, foretell the Last Judgment. Regardless of your religious beliefs or the extent of your theological knowledge, there are lessons which we can learn from these harbingers to avoid project failure.

The rider on the white horse is frequently identified as conquest, evil or, in mainstream pop culture as pestilence or plague. In the project context, a common infectious disease is chronic negativity.

Just like a contagion, it starts with a single dissatisfied team member or stakeholder who disagrees with the direction the project is taking, is disengaged or feels the project is doomed. While it is perfectly natural for folks to voice their concerns or to not always be positive, when this negativity becomes the new normal and nothing is done to manage the situation, other team members or stakeholders may interpret this lack of response as being an implicit validation of such behavior and it can spread. If swift action is not taken, the doom-and-gloom prognostications of Patient Zero can become a self-fulfilling prophecy.

Your role as a project manager is not to stifle others views or emotions but it is to be aware of them, and if you recognize that someone is sucking the energy and life out of the team, it is your responsibility to respond in a timely but professional manner. Often times the individual may not be sufficiently self-aware to know how their behavior is being perceived or how it is affecting others. In such cases an objective, one-on-one discussion may be sufficient to turn things around. These situations can also be a good wakeup call for a project manager – if morale has been neglected, it might be the right time to re-energize the group with some team-building activities or other types of recognition.

Another lesson to be learned from this horseman relates to effective change management. Ignore or marginalize the few who are actively resisting planned changes at your project’s peril. It is very easy for unmanaged change resistance to spread from them to the masses and even to infect those who you felt were the best advocates for the planned changes.

The red horse’s rider is generally interpreted as representing war. With the uncertainty which is baked into the DNA of projects and the high likelihood of team members having differing personalities, values and styles, conflict is to be expected.

Conflict is recognized as being a valuable driver of creativity and innovation so the goal should never be to eliminate it. Unfortunately, weak project managers are uncomfortable managing conflict and find themselves letting prehistoric “fight or flight” emotions drive their responses by either being autocratic and forcing resolution or avoiding conflict in the hopes that it will just go away. In both cases the conflict will fester, furthering the gap between the involved parties and increasing the likelihood of other team members or stakeholders joining the battle.
Escalating conflict impacts team morale, reduces productivity through distraction, and provides highly visible evidence of a project manager’s poor judgment and competency, and can often result in their removal from the project. There is no single panacea for resolving conflict but it is critical that a project manager recognizes it and responds at the right time in the right way.

Famine is how the black horse’s rider is usually identified and an obvious analogy could be drawn to the under-resourcing of projects. Unfortunately, in many cases, a project manager has limited authority over resource commitments, especially when working in functional or matrix organizations.

A different interpretation of the third horseman could be ineffective communication with the team and with stakeholders. Some project managers hoard or act as the gatekeepers on information. In such cases, team members are starved for the knowledge they need to be as productive as possible and velocity suffers.

In other situations, the issue may not directly impact the team, but might relate to how well the project manager is keeping stakeholders apprised of project direction and status. This can translate into dissatisfaction, misalignment and perception becoming reality as these stakeholders begin to fear the worst.

A project manager should not overwhelm recipients with information – situational communication which meets the information processing needs of stakeholders is key. The focus of the project manager should be to reduce distance and latency in information getting to those who need it to get their job done.

Ignorance of these three riders increases the likelihood that your project will encounter the fourth and final horseman who sits astride a pale horse – Death!

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

Some project management offices (PMO) are like Rodney Dangerfield – they don’t get no respect. While there are many causes for a PMO to be shut down, the inability to demonstrate their value proposition is one of the more common reasons.

So how can a PMO prove that there has been an improvement in project delivery?

To answer this question, we need to identify one or more metrics which will be used to represent project delivery capability. A commonly used metric these days is time to market which could be calculated as the duration from the start of project investment to the first delivery of customer-facing value.

You might think that it would be a simple matter of calculating the average time to market based on a sample of pre-PMO and post-PMO projects, but this is not statistically defensible. The sample size used to determine the average values might not be sufficient to prove that the difference is statistically significant. If variation has remained the same or has increased, even if the average time to market has dropped, portfolio-level outcomes won’t have improved.

Time to call your friendly neighbourhood statistician!

It might not make sense lumping all projects together for these calculations. For example, one might reasonably expect that a $10,000 project will usually take less time to deliver value than a $1,000,000 project. Project size and complexity influence timelines, so you might wish to stratify your population into a few distinct project tiers.

The next step is to determine the minimum sample size to prove that a difference is statistically significant. Statistical analysis packages such as Minitab enable you to calculate sample size based on the statistical test you will be running, the difference you’d like to see, and an estimate of the standard deviation of the population. For example, let’s say that we’d like to prove a reduction of one month in time to market, and the estimate of the population standard deviation is also one month. Minitab will calculate a minimum sample size of 18 projects. Unless we have at least 18 projects in both the before and after samples for each project tier, the difference in averages can’t be stated to be statistically significant.

Assuming you have sufficient data to support statistical testing, the two statistical tests you can run for each project tier are a 2-sample t test and a 2 variances test. The first will help you decide if the difference between the averages for the before and after samples is statistically significant or not, and the second determines if there is a statistically significant difference in the variation of the two samples. Ideally, after running the tests you will see a reduction in both the average time to market and the variation in the post-PMO sample. This won’t prove causality – there could have been other factors which more directly caused the improvement, but barring any obvious alternative influencers, you can state with confidence that things have improved since your PMO was established.

A key assumption underlying these tests is that before and after sample time to market data is normally or close to normally distributed – this can be confirmed using an Anderson Darling normality test. If it turns out that the sample is significantly non-normal, other tests would need to be used to statistically prove an improvement.

Disraeli was accurate when he said “There are three types of lies — lies, damn lies, and statistics”, but used appropriately, statistical testing can support the case for a PMO’s continued existence.

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

For many, the Holy Grail of PM tools are those that are able to automate all aspects of the project portfolio management life cycle.  There is something very appealing about being able to guide PMs, sponsors, stakeholders & team members through a methodology by removing any opportunities for inconsistent usage.  The assumption is that presented with a single path, everyone will dutifully follow that path resulting in higher quality decision support data for executives.

There are a few challenges with this Utopian scenario:

• A common cause of PMO failures is a lack of fit with their host organization – the same can be said for PM tools.  If the tools don’t fit the culture and maturity of the teams that have to use them, active or passive change resistance will impact tracking and reporting quality.
• Since there is no one size fits all projects PM methodology, the same will apply to the tools supporting the methodology.  Unless the PM tools are also able to support multiple approaches to the PM life cycle (e.g. big vs small projects, waterfall vs agile approaches), what works well for one project will be inappropriate for another.  Of course, if the projects are all of a particular type (e.g. implementing the same COTS application following a consistent process for multiple clients) this might be less of a concern.
• “Best practices” are only suitable if they are best for your organization.  Given the infinite variations on process workflows and information gathering needs, no single solution can claim to have a built-in set of best practices that will apply to more than a handful of situations.
• Removing flexibility from the PM process stifles creativity.  Unlike producing widgets where process control and total consistency of execution is needed, the uncertainty factor on projects requires people to think outside the box.  While I am not advocating the chaos that emerges from having NO processes or supporting automation, the opposite extreme is equally bad as staff run the risk of spending more time blindly following the processes than thinking for themselves.
• The tool shouldn’t replace normal delivery assurance practices.  It is a fallacy to assume that process compliance will automatically lead to improved project predictability.  PPM or PM tools are there to support decision making, and not to replace it.
• If your sponsors & stakeholders are not performing their roles appropriately based on human feedback, will system-provided feedback be any more effective?

A better approach might be a coach/mentor expert system – for example, the tool could suggest an appropriate decomposition level for the WBS, or could notify the PM if the risk register is getting stale.  It is still left to the PM to decide whether or not to accept the advice, but such a system coupled with a feedback loop (e.g. “was this advice helpful?”) could change the role of the automation from Big Brother to Bagger Vance.

(Note: This article was originally written and published by me in June 2011 on my personal blog, kbondale.wordpress.com)