Easy in theory, difficult in practice

I finally completed reading Nassim Taleb's book Skin in the Game which I had written about in a recent article.

In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.

In small companies, how a product gets developed and delivered is usually defined by a "Big Brain" (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.

Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.

For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won't themselves have to use the templates and tools which they have developed, they don't have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.

There are a couple of ways to rectify this situation:

• Serving in such control functions could be a rotational responsibility. After someone has spent a reasonable amount of time in a control role, they should be required to spend an equal amount of time in a delivery role. This will also help them better identify patterns and anti-patterns specific to a given context.
• Introduce performance measures and incentives for control staff which are tied to the impacts created by their work as opposed to just the completion of this work. For example, quantifying the cost of control or conducting regular satisfaction surveys with delivery staff are two methods in which we could bring back skin in the game.

Method makers and framework formulators - practice what you preach!

Although PMI has provided a glossary of terms in the back of the PMBOK Guide for many years, too many people continue to confuse others (and themselves) through the use of some common terms.

Sure, a rose by any other name would smell as sweet, but in our profession we have a hard enough time bridging expectation gaps to make things worse by calling a spade something other than a spade.

In no particular order, here they are:

Project charter: The document that PMI defines as “a document issued by senior management that formally authorizes the work of the project to begin (or continue) and gives the project manager authority to do his job” has been confused with everything from a project plan to a vendor contract to a Statement of Work.  As the name itself implies, a charter is needed for “chartering” – it is not the plan.  The plan should follow the charter and not the other way around.

Project plan: As per PMI, the project plan is “a formal, approved document that defines how the project is executed, monitored and controlled. It may be summary or detailed and may be composed of one or more subsidiary management plans and other planning documents”.  However, if you were to ask most people what a project plan is and they will very likely say “that’s what you create in MS Project”.  Not only does this create confusion, but it also reduces the perception of the planning phase of a project to “creating the schedule”.  Forget about risks, budgeting, quality, scope, communications, procurement, human resource planning and so on.

Risks vs Issues: This has become a standard part of every risk management presentation or consulting engagement that I do.  I’ll never assume that the audience understands that a risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives”.  Although PMI does provide a definition for an Issue, I prefer to define an Issue as an event that has occurred that, if left unresolved, will impact one of the objectives or success criteria for a project.  Many times when I ask a client to describe their project risk management methodology what I will get is a review of their project issue practices.

You may wonder why I wrote an article on this – this lack of consistency and precision is a contributing factor to why project management has struggled to be recognized as a profession.  The work of associations like PMI, IPMA and others is helping, but we (as the practitioners of the profession) need to incorporate this consistency into our daily interactions.

(Note: this article was originally published on kbondale.wordpress.org in September 2009)

For many years, my personal e-mail signature has been a quote from David Maister's book on professional service management: "Customer satisfaction = Perception - Expectations". This formula simply but elegantly captures how we feel when our expectations are either exceeded (or the opposite) when acquiring a product or receiving a service.

The Kano model provides a theory for product development and customer satisfaction. In an earlier article, I tried to connect this model and project management, but having just experienced an example of how past experiences can impact expectations and perceptions, I felt a follow up piece on Kano was warranted.

As a refresher, Kano's original model provided four broad categories for product features: Must-be, attractive, one-dimensional and indifferent. I will describe these and provide examples from the personal automotive industry.

• Must-be attributes are sometimes referred to as hygiene factors as they must be part of a product or service but gold-plating won't result in greater satisfaction. Seat belts on a car are one example of these.
• Indifferent features are those which don't positively or negatively impact customer satisfaction regardless of their presence or absence. Fuzzy dice hanging from the rear-view mirror would likely fall into this category for the majority of car owners.
• One-dimensional attributes are those which demonstrate a linear relationship to customer satisfaction. Seating surfaces in a car are one example of these. While I will be happier having leather seats than cloth seats, I am not likely to be exponentially happier.
• The final category is attractive which are often referred to as delighters. These are those attributes which are unexpected but will excite or delight a customer. Heated steering wheels for purchasers in colder climates were an example of these a couple of years back.

While this categorization is helpful and can be used to support product feature decision making, the theory also suggests that over time, attributes we used to find attractive become one-dimensional and might even drop into the must-be category.

I spent the past week relaxing at a Caribbean resort. This was my third trip to the same resort and a contributing factor in the decision to return a third time as well as the reason I had strongly promoted this resort to others was the magnitude of recognition I had been shown upon my second visit last year. This recognition far exceeded any expectations I might have had so the specific nature of the recognition clearly fell into the attractive category.

Given how far my perceptions had exceeded my expectations on my second visit you can understand why I would have similar expectations for a third visit. The attractive had now become a one-dimensional. Unfortunately, reality fell short of expectations and while my overall experience at the resort was pleasant, I still felt let down.

Past perceptions set expectations.

If you delight your customers once but fail to do so on subsequent transactions, don't be surprised if they are dissatisfied with otherwise acceptable levels of service.

As we kickoff the final week of 2018, many of us will be making New Year's resolutions. While some of these resolutions might relate to achieving a specific goal or objective (e.g. I resolve to run a marathon this year), most relate to changing our behavior (e.g. I resolve to eat healthier this year).

But for many of us it becomes a case of déjà vu as we end up making the same resolutions we had confidently made in previous years.

Increasing organizational agility is a journey and not a one time goal.

Similar to New Year's resolutions, some delivery teams initiate plans to become agile only to revert to long ingrained habits when things get tough. It might not be on an annual basis, but companies which have struggled with agile transformations once will often try again and many will experience more than one failed attempt.

When it comes to personal resolutions and being able to stick to them the American Psychological Association's website provides some good advice which could be applied to agile transformations.

Start small

It might be tempting to pick the very largest product or project when starting an agile transformation to surface many key organization blockers and to glean some valuable lessons. However, the very visible impacts of potential failure as well as the higher volume of stakeholders whose behavior will need to change makes this extremely risky. Just as a casual runner shouldn't try to run a marathon in their very first month, starting with too ambitious a set of pilot initiatives is usually a recipe for disaster.

Change one behavior at a time

There are multiple behaviors which leaders and team members might need to modify and trying to change all of those at one time is like a golfer who tries to keep multiple swing thoughts in their head when addressing the ball. Usually they will end up with a worse swing than if they had just cleared their mind of all thoughts! A transformation team should identify which behavior change might result in the biggest impact and that should become the focus of coaching and peer support.

Talk about it

To succeed with any significant organizational change we need to over-communicate. The more we can talk with stakeholders about our target operating model, the challenges we will face to get there, and the small wins we are achieving, the more we will remain committed to the journey.

Don't beat yourself up

No agile transformation is going to go smoothly. Some initiatives might turn out worse than if a traditional approach had been used. Some staff will leave the organization. As the APA website states "Perfection is unattainable". But as long as we have support mechanisms in place and a desire to get better, we can bounce back from such setbacks which are usually minor when viewed from the perspective of an end-to-end transformation timeline.

Ask for support

Every organization has a unique culture, but it can be easier to stick to an increased agility resolution when you have support from those who have been there and done that. The value of external support comes from the breadth and depth of experience to know which patterns of behavior or practice are likely to lead to success and which won't.

Adapting the quote from Dr. Lynn Bufka "Remember, it is not the extent of the change that matters, but rather the act of recognizing that lifestyle behavior change is important and working toward it, one step at a time."

I attended a thought provoking session at PMI’s 2010 Research & Education Conference which covered factors necessary for project managers to successfully manage multiple concurrent projects.

The research was done based on a single large financial organization focusing on their IT project portfolio.  However, the findings from the research align very closely with anecdotal evidence from past clients and industries I’ve worked with.

The top two factors (in order of priority out of a set of five in total) identified as contributing to effective multi-project management were:

• Teamwork oriented culture (organizationally)
• PM competency

The second factor is no surprise – good staff can overcome bad processes and tools to deliver expected results so long as they are pointed in the right direction and suitably motivated!

The first factor is less obvious, especially since it trumped other factors including consistent PM process & methodology, sufficient & sustainable people allocation and consistent practices for selecting & assigning PMs to projects.

However, think about the challenge of managing multiple projects when you DON’T have a good teamwork oriented culture.  There will likely not be individual commitment to work products, reward for performance, open communication & team work.  If these attributes are not present, a PM spends a significant amount of time escalating people performance issues, trying to motivate disengaged team members and chasing after “invisible” stakeholders and sponsors.  While this is aggravating on even a single project, a PM with sufficient experience and influence can still succeed.  However, when managing multiple concurrent projects, the PM does not have the luxury of time to focus on this and this will impact their overall effectiveness.

Understanding that the need for concurrent project management is not likely to go away anytime soon, organizations need to ensure that they increase their PMs odds for success by fostering a suitable organizational teamwork oriented culture.  This could start by introducing team member evaluations tied to performance on projects, providing basic PM training for all team members, and requiring commitment to accountability for all staff.

(Note: this arrow was originally shot in July 2010 towards the target of kbondale.wordpress.com)