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.
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 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)
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 online discussion groups is "Should I get my XYZ PM certification?", so I felt that there might be some value in assessing the most common justifications.
While this article is not written to make you avoid knowledge-based project management certifications, hopefully it has helped with the decision-making process.
(Note: this article was originally written and published by me in April 2011 on Projecttimes.com)