Easy in theory, difficult in practice

A question that is frequently asked in online project management communities is "How critical or valuable is it for a project manager to have detailed subject matter expertise or technical competence related to the scope of their projects?".

To clarify, I am not referring to business or process knowledge - I believe that a PM has to have a good understanding about how the deliverables of their projects will be used and they should have sufficient process awareness to help identify the project and business risks that may reduce benefits realization upon project completion.

Here are a few of the benefits to having "hands on" knowledge and experience:

• The ability to help with brainstorming possible solutions to issues as well as the ability to contribute more extensively to risk identification, analysis and response
• When the team gets into a crunch, the ability to pitch in and keep the schedule on track.
• Better ability to validate effort estimates from the team
• It can ease the process of earning respect from team members
• Avoiding the risks related to "I don't know what I don't know"

However soft skills don't usually increase from having technical competence, and yet, these soft skills are often the biggest source of challenge for PMs.

Beyond this concern, there are other risks to be aware of:

• We often default to giving higher priority to those tasks that we are most comfortable with - especially when we are under stress.  For a novice PM, this could mean focusing on hands on technical work and neglecting core PM activities.
• Whereas a PM with limited technical experience is likely to seek knowledge from subject matter experts, a technically competent PM might simply make an assumption based on past experience - since no two projects are the same, what was applicable in one situation may not be applicable in another. 
• Unless the PM is making an effort to remain technically current, their knowledge might be obsolete which increases the potential for poor decision making.
• There is an increased likelihood of deliverables micro-management or for technical head-butting with team members.

With constraints forcing organizations to cut costs when staffing project teams, a PM is often expected to perform multiple roles.  While this approach can increase the value the PM brings to the organization and is one way of introducing someone to their first PM role, it presents risks that a PM should be aware of and should manage through courage and self-awareness.

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

The best activity estimates will not help to bring your project in on time if the underlying estimates of team member availability are inaccurate.

I’ve written extensively about my belief that the inability to accurately estimate team member availability is an equally critical, but less publicized project risk than poor scope management, requirements challenges or bad governance.

In project-oriented organizations, this risk may not be realized as staff are dedicated to specific projects and until they complete their assigned activities on those, they are not likely to handle a different project.  In such environments, the main source of team member risk is likely to stem from unexpected attrition or reduced productivity.

However, most of us work for matrix or functionally structured companies.  In such organizations, it is very rare that a team member would be fully assigned to a project.  Most likely, staff are splitting their time between multiple projects and many will also have operational responsibilities.  Frequent readers will know about my loathing for multitasking and this infographic provides a very powerful depiction of the negative impacts.

When team members split their time between project and operational work, regardless of the maturity of the project estimation process, estimating operational utilization is as predictable as attempting to forecast (with any great deal of accuracy) what will happen in the stock markets.

You might argue that if time tracking is being done, it should be possible to come up with a reasonable estimate based on the previous year’s actuals.

Let’s take the example of IT analysts who split their working time between project and operational work with the majority of this operational work relating to resolving production system and application outage issues which cannot be handled by first-level support staff.

Just a couple of the factors which could significantly reduce the accuracy of a previous year’s production support time actuals are:

• If the technology infrastructure has increased in complexity (e.g. if projects completed in the last year have increased the magnitude of the base asset), support work could increase.  Conversely, if there has been a simplification in the complexity of the technology infrastructure as compared with the previous year, support allocation may decrease.
• If the number of users on the systems supported, or the number of other analysts who perform the same support function changes.

The silver bullet to slay this particular PM werewolf is simple – don’t have project staff also handle operational work.  Unfortunately, in many organizations, a lack of cross-training or simply insufficient staff renders that option infeasible.

If so, the next best option may be to use actuals from a previous year, but to calculate and apply a weighting factor which attempts to analyze what has changed.

To plagiarize the popular mutual fund prospectus disclaimer: Past actuals do not guarantee future availability!

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

One of the more prevalent myths with agile delivery approaches is that the project manager should let the team develop their own working practices and rules of engagement to manage themselves.  While this sounds great in theory, in many cases it will result in disaster.

No question, in times of crisis over usually fairly short durations a team of professionals can develop creative ways to work together effectively and productively to resolve the situation but this doesn’t translate well into the world of most projects where the sense of urgency or shared goal is usually insufficient by itself to encourage productivity and efficiency.  While testing this hypothesis might make for a good social experiment and has been utilized regularly on reality TV shows such as The Apprentice, few organizations will want to take chances with their critical projects.

I’m not advocating the anachronistic use of rigid command and control practices on the part of the project manager.  While a lack of attention and guidance to work practices and results may result in chaos, being a slave driver is almost guaranteed to cause project failure along with permanently damaged relationships between the project manager and team members.

As with other project management situations, this becomes a balance between the “what” and the “how”.

The project manager needs to ensure that the team had a clear, consistent understanding of “what” the expected project outcomes and benefits are as well as “what” the key deliverables and activities are.  The project manager also should set expectations and require compliance with “what” he or she needs to develop plans and to track and report on progress for the project.

However, when it comes to “how” the work gets done and “how” progress reporting and other normal practices will be performed, the project manager should provide the team with the flexibility to explore and develop the most efficient method for them.  This doesn’t mean starting with a blank slate or letting the team radically change directions on a weekly basis.  It does mean reviewing the organization’s standard or de facto practices at the start of the project and educating the team on why these practices are important and then giving the team the opportunity to adapt these practices and to regularly review them during retrospectives.

Moving to a more “black box” approach to work management provides greater empowerment of team members without the risks implicit with totally abdicating management responsibility.

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

Demos, reviews or showcases as they are sometimes called, are a critical ceremony when they are run effectively as they address multiple project delivery objectives in a single event including:

• Validating that what the team has completed to date is valuable from the perspective of their customer and other key stakeholders
• Helping the team and stakeholders change or evolve their understanding of the desired solution
• Getting signoff on completed work items in those organizations where such signoff is a required prerequisite for implementing change
• Facilitating transparent progress reporting as stakeholders see what was committed by the team and what was completed
• Providing team members with regular feedback and recognition for their hard work which increases levels of engagement and job satisfaction

But demos are just like any other project delivery practice in that their misuse could result in a worse outcome than if they had been skipped entirely. Here are some do’s and don’ts to help increase the value your organization gets out of demos.

• DO send meeting invitations well in advance and if you are following a standard sprint or iteration frequency (e.g. two or three weeks) then schedule a set of recurring invitations
• DON’T book demos on Friday afternoons to avoid having stakeholders who are absent in body or mind
• DO share the wealth by having everyone on the team take a turn to present a demo
• DON’T use the demo as your soapbox for complaining about the team, blockers or what could or should have been done different
• DO provide objective context when sharing sprint or iteration outcomes (e.g. committed vs. completed)
• DON’T present a demo without having tested what you are going to show beforehand
• DO invite both your customer representatives and relevant control partners to your demos
• DON’T overwhelm your stakeholders with content
• DO record the presentations either in advance or (if you feel lucky!) during the demo itself for the benefit of any stakeholders who were unable to attend
• DON’T take negative feedback personally

While this article is applicable for teams who are using an agile delivery approach, it is equally suitable for traditional projects.

Dazzling demos will help sustain the attention and support from your customer and will focus your team members on value delivery.

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

When we think about what facilitates successful organizational change, we tend to think of visible sponsorship, active engagement of those involved in the change, and incrementalism.

However, I was reminded of two other important pieces to the change jigsaw puzzle after reading the book Agile Change Management: Trust and talent.

You might take exception to the first one and say that trust is necessary for any business interaction or transaction to succeed.  While that is true, there is a greater need for trust when people are being asked to leave their comfort zones and adopt new processes or tools.  When there is a high level of trust that the leadership team is looking out for them and acting in the best interests of both the organization and its people resources, there is a stronger likelihood that staff will take a leap of faith.

When staff distrust the intentions or actions of their leaders, they may say that are going to embrace a change and might even begin to adopt it.  Unfortunately, their commitment to staying the course is likely to be brief, especially if they hit the inevitable challenges which come with trying something new.  When this happens, they will regress to previous practices defending their behavior by saying that they did give the changes a fair try.

We’ve seen this happen frequently in the world of politics – citizens will blissfully vote against their self interests simply because they don’t trust the person who is pushing a platform which is beneficial to them.

Melanie Franklin, the author of the book, references talent in relation to those implementing the change – this is obviously important since the change will not be implemented as effectively or efficiently by those lacking necessary skills and further, the perception of the change will be sullied in the eyes of those impacted by the change.  Her logical assertion is that when we work on things which we are good at, we tend to derive more satisfaction and are more engaged in the work.

I’ll go one further and say that talent is an equally important consideration in those who are expected to adopt the change.  Nearly all change implementations including a communications and training component to help adopters learn new practices.  However, many times the change team does not consider whether the necessary prerequisite behaviors and skills are in place to ensure that the training they are providing will achieve the desired objectives.

My favorite analogy is that of teaching a caveman how to use a rocket-propelled grenade launcher.  You might educate him on the importance of a firm stance to absorb recoil, but without foundational understanding, he is as likely to fall to the ground and worship the weapon as he is to use it properly!

So the next time you are managing a change initiative, add these questions to your impact assessment checklist:

1. Do those about to be impacted by the change trust those who are implementing and championing it?
2. Do those who will be impacted by the change have the necessary foundational skills to successfully adopt it?

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