Easy in theory, difficult in practice

Here’s a (lighter) take on the etymology of some of our common PM terms:

1. Milestone – originally “millstone”.  A large, heavy object used to grind resources that can also be used to defeat a project manager’s attempts to stay afloat.

2. Scope – short form for “endoscope“.  A tool used to look inside a customer’s body to identify what ails them.  Wielding scope  (also known as “scope control”) usually results in discomfort to the customer with monetary gains for the wielder.

3. Budget – from the old French word, Bougette – a purse.  Usually this purse’s strings are welded shut by your project sponsor.

4. Sponsor – the term originally signified an experienced individual that would guide you through a growth initiative such as a twelve-step program.  In recent years, the term has changed in to identify someone that is likely to put you into Alcoholics Anonymous.

5. Issue – The act or an instance of flowing, passing, or giving out.  The key definition to extract from that last sentence is the “the act of passing out” as that is applicable to a project manager that has logged one too many issues.

6. Monte Carlo simulation – Named in honor of the famous casino to warn practitioners that at some level, project planning is the same as gambling – once you think you’ve created a predictable plan for your project, you’ll usually go broke.

7. Critical Chain – The chains that were used to bind rowing slaves to their benches on merchant ships.

8. Progress – A Russian expendable freighter spacecraft.

9. Baseline – an imaginary line or standard by which things are measured or compared.

10. Stakeholders – The assistants that Dr. Helsing employed to hold the implements that were used to eliminate Count Dracula.

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

Many of the articles I’ve written and presentations I’ve given have focused on reducing the impacts of organization, process or technology changes on staff.  Having said that, an issue I perceive with many of the clients I’ve worked with is the assumption that such changes come at no cost or pain to affected staff.

I would be hard pressed to think about any strategic change initiative that I’ve been involved with or have witnessed that did not leave some carnage in its wake – leadership’s focus should be on minimizing or proactively controlling damage, but not on attempting to create a state of no churn.  Otherwise, you are not implementing change, you are trying to maintain the status quo or to satisfy the totality of a democracy.

This illusion that change comes at no cost is dangerous –  Information Week had published a good article a decade back on the leadership team at Rockwell Automation – the line that stuck with me from this article is from their CIO: “Our business processes and practices will change significantly, and we will accept some disruption to achieve the ultimate benefits.”

This assertion acknowledges two key principles:

1. Change hurts – someone, somewhere in the organization is not going to be happy or will struggle with the change, no matter how logical, beneficial or commonsensical it may be.

2. The net benefits realized from a change are rarely achieved right away, and will likely take longer depending on the magnitude of the change.

Now this might seem completely obvious to all of you, but think of how many projects you’ve worked on where a basic expectation was that there would be no disruption to operations stemming from the deployment of the project’s deliverables.

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

A close variant of the saying “Forewarned is forearmed” has origins dating back to the 1500’s (and possibly even earlier).  This came to mind when evaluating the role of risk acceptance as a valid risk response strategy.

Risk acceptance is often treated as the odd cousin thrice-removed that no one wants to remember or mention in polite company.  The terms “acceptance strategy” itself appears to be an oxymoron  – acceptance conjures up thoughts of inertia while strategy inspires action.  While documenting their risk registers, project teams feel good about those risks that can be mitigated (good), transferred (better) or avoided entirely (best) – acceptance seems a weak approach and they fear that sponsors or stakeholders might view the team in a poor light for bringing them problems instead of solutions.

Such environments are clearly risk immature – it is unrealistic to expect that all “known unknowns” can be controlled on anything other than the most basic project.

So what are the benefits of the risk acceptance strategy?

• Communicating a risk is of benefit even if we can’t do anything about it.  We are better able to deal with “known unknowns” than truly unexpected events.  The latter often causes us to instinctively use our lizard brains resulting in fight-or-flight decisions that (should) have no place in business situations.
• Acceptance does not mean “do nothing”.  While little might be done actively in advance of a risk being realized to reduce its probability or to diminish its impacts, nothing prevents a project team from preparing contingency plans to be executed if it is realized.  In many environments, an acceptance strategy may have a better chance of success than a more active one – proactive risk response plans are often not executed due to a lack of priority or resources, but developing a contingency plan may be more palatable.
• Avoiding deja vu.  A risk that is accepted on today’s project might be one that could be actively addressed on a future project.  Risks of any sort are a good source of lessons learned, but accepted risks need to be considered with greater gravity if we don’t want to repeat past mistakes.

Perhaps the issue is with the term “acceptance” itself – maybe the next edition of the PMBOK Guide and the Project Risk Management standard might consider a less fatalistic term such as “acknowledgment”?

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

A March 2016 HBR article shared the results of the first round of a research study conducted by Dr. Sunnie Giles, which focused on identifying a short list of key leadership competencies. The study involved the participation of 195 leaders from 30 organizations in 15 countries.

The article provides examples of how these competencies can be demonstrated by executives or functional managers. Project managers are equally responsible for exhibiting these behaviors so here are some ideas on how each of the top ten traits can be applied within the project management context.

Has high ethical and moral standards

As a project manager, you have the responsibility to act with integrity and fairness in your dealings. Your behavior sets the standard by which your team members will operate. If you are a member or credential holder with PMI, this privilege comes with the requirement to follow the PMI Code of Ethics. Beyond the impacts your actions have on your project stakeholders, if you compromise these standards you are also damaging the credibility and reputation of the project management profession.

Provides goals and objectives with loose guidelines and direction

You must ensure that your team members have a clear understanding of what a project’s expected outcomes are and why the organization is investing in it. However, this shouldn’t be mistaken as permission to micro-manage the team’s work. While you do need to monitor and control performance, the emphasis should be on encouraging your team to come up with the most efficient and effective means of achieving the project’s objectives while removing hurdles from their path.

Clearly communicates expectations

In functional or weak matrix organizations, you might have limited or no formal input into the performance evaluation of team members. In spite of this, if you don’t effectively set expectations with them as part of their onboarding to your team, you shouldn’t be surprised when issues arise. Once again, I am not giving you carte blanche to dictate every step of how their work should be performed. You should make it clear what your needs are as far as reporting and control and then help the team to develop as a set of practices which will fit their working style while still meeting your requirements.

Has the flexibility to change opinions

You have to make a number of decisions over the course of any project, but one of the attributes of a good project manager is the ability to help team members and other stakeholders lift their heads out of the sand if they are affected by tunnel vision. Increased stress levels cause people to narrow their focus so this is where mindfulness techniques can help you get some perspective and redirect the energy of the team.

Is committed to my ongoing training

Successful project management is not just about reaching a destination – the journey is equally important. If you don’t take the time to learn what the development objectives are of your team members, you aren’t fully answering the WIIFM question for why they should commit their efforts to your project.
Even if the scope of the project is virtually identical to multiple projects they’ve contributed to in the past, you can still provide them with stretch opportunities to help their further development. And when it comes time for them to leave the project, act as a champion for their development objectives with their people managers.

Communicates often and openly

More than 90% of your time will be spent communicating, and ineffective communications have frequently been identified as a contributor to project failure - enough said!

Is open to new ideas and approaches

As project managers, we are on the pointy end of change, but it’s amazing how often we are unwilling to consider an alternate approach to an issue or decision. One of the quickest ways to stifle the creativity of your team will be to take the “my way or the highway” approach – it won’t take too long for them to realize that their ideas aren’t really being considered.

Strive for an eclectic set of skills and backgrounds when negotiating for team members – the greater the diversity, the greater the likelihood of unique solutions.

Creates a feeling of succeeding and failing together as a team

Although your team members come from different departments that doesn’t mean they won’t be looking for the opportunity to connect and form bonds with peers from other areas of the organization. Helping to create those connections and focusing on team building efforts throughout the project’s lifetime will increase the likelihood that your team members will act in the best interests of the team and the organization as a whole.

Helps me grow into a next-generation leader

Every interaction with our team members provides the opportunity to coach them and encourage the development of their own leadership skills. My own interest in the profession was sparked by a project manager who “walked the talk” that the role is more than just tools and techniques. How you conduct yourself in challenging situations will make a lasting impression on your team.

Provides safety for trial and error

If your project microcosm reflects the fear of failure culture of your organization, creativity and efficiency suffer as team members stick to tried-and-true approaches and frequently employ wasteful CYA techniques to shield themselves from the consequence of failure. You are in the best position to create a working environment where your team members can afford to fail fast, learn from their failures and succeed.

Developing leadership competencies such as these will not only raise your profile within your company but will provide a good standard of behavior for the stakeholders whom you work with.

As with quality, elevating organizational capability is everyone’s responsibility.

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

Sprint planning is one of the standard events within the Scrum framework.

This ceremony or an adapted version has also been incorporated within other agile delivery frameworks which time-box the work of teams. The purpose of the ceremony is to align the team on what they will be working on during the upcoming sprint to ensure that their efforts are focused on delivering the highest priority work items in a quality manner while maintaining a sustainable pace of work.

Successful sprint planning lays the foundation for a successful sprint but this just completing the ceremony doesn't mean it is delivering value.

Here are four common challenges which impact this critical ceremony.

Where is everybody?

Sprint planning is that singular opportunity to get everyone's buy-in on what will be accomplished in the upcoming sprint. Partial participation means that decisions are being made on behalf of team members who are not in the room. That is likely to reduce their sense of ownership for the sprint backlog and increases the risk that work may be accepted which cannot be successfully delivered without heroics.

While it might be convenient to conduct this ceremony first thing in the morning, the team should develop a sense of when they are likely to be fully present in mind and body and schedule it accordingly. Similarly, it is not advisable to start sprints on Mondays as that tends to be a more common day off than the middle days of the work week.

A lack of preparation

If the backlog doesn't reflect the Product Owner's priority, sprint planning is not the time to bring it up to date. Similarly, while highly mature teams are able to complete task identification, modeling, sizing or other preparatory activities during sprint planning, most others find that spending some effort in the previous sprint doing some look ahead planning will reduce the likelihood of running out of time in the ceremony or slicing off a sprint backlog with only a limited understanding of what needs to get done.

Appetite exceeds capability

Its normal for new teams to accept more work in a sprint backlog than they are realistically capable of delivering. However this gap between expected and actual velocity should reduce progressively sprint over sprint.

When a lack of predictability regarding team capacity is not a blocker, teams which consistently take on more work than they are able to deliver are either demonstrating a lack of self-discipline or they lack the courage to educate demanding stakeholders on the dangers of accepting unrealistic commitments.

It's my way or the highway

Whether it's the Product Owner or a (supposedly) observing senior stakeholder, there's no excuse for the development team being told how much work they will accept in a sprint.

Does your team experience any of these dysfunctions? Is your team sufficiently self-aware and transparent such that these challenges are identified during retrospectives? If not, why not?