May 8, 2014

The Agile Balanced Scorecard

How would you picture an Agile organization?

The traditional balanced scorecard offers a good starting point because it looks at the key perspectives that make an organization successful today and tomorrow.

However, some adapting needs to be done:
  • From Financial to Business value
  • From Internal business processes to Operational excellence
  • From Learning and growth to Future orientation
  • Customer remains unchanged

Beyond wording, the Agile Balanced Scorecard shows that the Agile organization has a different personality than the traditional one, as reflected by the key characteristics of each of the four perspectives.

 
Sources:
Business agility (Wikipedia)
Balanced Scorecard for the Agile Enterprise (Asheesh Mehdiratta, Pitney Bowes, Agile Tour 2011)
Radical Management (Stephen Denning)

April 16, 2014

To initiate change, make it ugly!

When the prospect of change arises in an organization, there is little more than a general feeling of “we should do something about it”. However, stakeholders seldom agree about the “something” to do, the “it” to solve, and even whether the change is necessary or not.

In organizations with adaptable culture, structure, and processes, we can rely on positive stimuli to initiate change, such as leveraging business opportunities and the excitement to improve and learn. Rigid organizations, on the other hand, tend to change only when forced to.

Changing a rigid organization requires to generate a sense of urgency. Easier said than done! We’ll see concretely how to create a sense of urgency to initiate change.

  1. Make sure key stakeholders agree there is a problem
  2. Squash “business as usual” solutions
  3. Propagate sense of urgency to all those who will be involved in the change


1. Make sure key stakeholders agree there is a problem


First, we have to make sure stakeholders agree there is a problem and that not dealing with it is not an option.

Indeed, as long as stakeholders with power question whether the change is necessary or not, it is virtually impossible to make any significant improvement. In the real world, these resisting stakeholders are typically the ones who tell you that “this is the way it has to be done”, that “we already do that”, or that “it’s because [insert external factor we can do nothing about]”.

It may sound a bit reckless, but the key here is to make the problem big and visible. Make it ugly.

One of my missions involved facilitating collaboration between business and IT parts of an organization in order to deliver solutions in a timely and cost-effective manner, which they were entirely unable to do. I faced with stakeholders that denied the importance of the problem and their responsibility in it. In this case, it was not possible to count on goodwill to trigger change. A shock was needed.

To illustrate the problem, we showed that legitimate business requests accumulated 2-to-3 times faster than the organization could deliver them with the current way of working. The forecast demonstrates that the situation was not sustainable if nothing changes.



A few important points here:

  • Keep the visuals simple. Use simple metrics and terminology. Stakeholders must be able to understand it at a glance.
  • Have data to back analysis. The question “where do these numbers come from?” will inevitably pop up.
  • Urgency of the situation must be undeniable. I noticed that showing three scenarios such as best case, worst case, and most likely, and showing that even best cases fails, is a good way to avoid doubts.


2. Squash “business as usual” solutions


Second, squash fake solutions.

When showing your big “status red”, well- (and not-so-well-) intentioned people will come up with traditional solutions such as increasing budget, hiring people, or reducing scope, to name a few. These solutions might work for simpler, smaller problems, but are not realistic for the situation at hand. Not only the traditional solution can seldom be implemented (e.g. there will not be any additional budget), but on top of that it will not address the root cause (e.g. increasing the budget would only improve situation somewhat and for some time).

The real solution requires drastic change that is beyond administrative solutions; it affects one or more aspects of organizational structure, processes, culture, and technologies. In other words, we have to show that dealing with the problem “the usual way” will not solve it.

Actually, in my experience the biggest pitfall of initiating change is that the change initiative is quietly downgraded to a project among others.

Don’t wait until these so-called “alternative solutions” pop up around you, as it may stall the legitimate change initiative. Instead, address them right away and show how unfeasible or inferior they are. Use a decision-making comparison table for example.



3. Propagate the sense of urgency to all those who will be involved in the change


Third, communicate like crazy to make stakeholders understand how bad the situation is and how the change initiative can solve it.

Indeed the previous steps will likely be limited to a small number of key stakeholders. Any significant change affects tens, hundreds, even thousands of people.

Some will be excited for an opportunity to finally improve painful aspects of their work. Others will be scared, and that’s good too. Only indifference poses a problem.

By now, you should have a both a sense of urgency and a coalition in place, which incidentally are the two first steps in Kotter’s change model. Now you are ready to propose a solution for change. If you had proposed a solution for change – even a wonderful one – before having completed these preliminary steps, you would have hit a wall as there was neither admission of the problem nor people to support you. Note that these steps can take anytime between a few days to a few months, so be patient. In the experience mentioned above, which is a particularly difficult context, it took two months of intense lobbying and gruelling fact-gathering to reach this point.

In conclusion, the hardest part of the change process is to generate a sense of urgency to initiate the will to change. Although the natural way to initiate change is to motivate with positive outcomes, this approach only works if the organization is adaptable. In a more rigid, bureaucratic organization, people have to feel the urgency to consider going against the flow. However, both approaches are complementary; in a rigid organization positive motivation works best after a sense of urgency has been attained. When a sense of urgency starts appearing, there is also the risk that traditional solutions are proposed, which would fail to yield results because they do not address the root causes. Finally, the problem must be made visible to all those who will become stakeholders in the change effort and not just the sponsor and key stakeholders.

January 27, 2014

Does PMI-ACP (Agile) certification matter?

I had the opportunity to do agile project management for years and passed ACP (Agile Certified Practitioner) last year. Several people asked me what I thought about ACP, so I figured it's a good time to share impressions, rather informally.

ACP certification makes sense because:

1/ It focuses on project management, not just team management, i.e. it includes risk management, communications management, etc.

2/ It is not limited to software development

3/ It is not easy to obtain, unlike some well-known certifications that have become quite hollow - ACP is a differentiator

4/ It complements PMP in the sense that PMBoK describes *what* the PM should know, and ACP describes *how* to do it the agile way

5/ It's a pretty good state-of-the-art tour, as it does not focus on any single agile framework/approach

6/ It goes beyond the tiresome "agile mindset" abstraction by requiring understanding of actionable practices

7/ It recognizes the fact that successful project management is more about soft skills than about project management techniques (as any experienced PM will confirm)

On the downside, I feel it's not easy to prepare because unlike PMBoK there is no accepted "AgilePMBoK". ACP refers to a bunch of books and often requires answering questions for which there is not consensus regarding correct answer. Some would say that "agile certification" is a paradox because agile approach discourages standardization. (although I had the chance to set up agile standards in organizations on more than one occasion - the trick is the appropriate level of detail and adapting to context - but that's another topic).

Hope to see more PMs knowledgeable in Agile!