Change

"The problem with the future is that it isn’t what it used to be" - A.C.Clarke

Confession time. I am old enough to remember going into a major bank in the mid-60's to open an account (which I still have). I also remember the confusing set of product choices I was offered – ONE! IN 2008, as the credit crunch was being felt around the world, the number of mortage products being offered in the UK was reduced as banks became wary of lending money for houses. The number of mortage products dropped from 15,000 to 9,000!

Over the past 5 years, I have asked many senior managers including C.E.O.s the following question.

"How far into your organization's future can you predict with certainty. That is, before some regulatory change, competitor initiative, restructure or one of your key people leaves?"

The answer will not probably surprise many of you reading this.

"Three months maximum."

Welcome to the 21st Century.

The causes of this instability have been well documented in books, papers, magazines and other media.

They include:

• Globalization – the continuing rise of China, India, Vietnam as alternative and cheaper sources for knowledge workers;
• Competition – the deregulation of finance, power and other previously protected sectors has given rise to unprecedented levels of competition;
• Regulation – paradoxically as the previously closed sectors were opened up, the need to control/regulate their behaviours increased (welcome to ENRON);
• Rising expectations – as consumers become more aware and more empowered through travel and the internet, their expectations have grown;
• New social contracts – most orgnaizations have recognized the need for more flexible and shorter-term working arrangements both from theirs and their peoples' perspective. Welcome to the Free Agent Nation.

The implications of this rate of change for project management are fundamental to the practices of Agile Project Management.

Change is bad was one of the underlying principles or traditional project management. Should one of the "users" (an official Agile bad word – see the Evolution: The use and abuse of expert power paper on this site) want to change their requirements after signing the requirements document, they were, in effect, punished. Using an approach similar to the "variations" model used in construction, the user was subjected to a bureaucratic, complex and time-wasting process of submitting change requests, which typically were delayed using the infamous "We’ll give it to you in Phase 2" ploy.

Change is normal.

Instead of seeing this as another glib statement .. really think this through.

The implications of this statement for project management are far-reaching.

They include:

• The change process must be agile, light touch and quickly reflect back to the stakeholder the impact of the change and the alternatives available for the stakeholder;
• Sponsors must be available on-demand to approve the changes as fast as possible;
• There will be almost constant turnover in your project stakeholder community, team and worse, sponsors;
• Projects will spend more time in "Red" status as changes will typically require some re-baselining of the plan;
• Schedules beyond 3 months will probably be incorrect (see Contingency).

These and other impacts are discussed in more detail on this site.
by Rob on 5 Feb 2011

Organisation Culture & Agile

When I was initially taught project management in the mid-1970’s, I learnt about GANTT Charts, scheduling and all the elements of Traditional Project Management (the history of project management in on our related Web Site www.thomsettinternational.com). However, later I began to understand, that while I was learning about project management techniques, I was also subconsciously learning something even more powerful – project management culture. A set of values and related behaviours, that had developed in construction, engineering, science and the military.

Traditional project management (TPM) is the end result of the evolution of project management over thousands of years. It was adopted with little change from construction and engineering and has become the predominant body of knowledge for business and IT project management .

Agile project management (APM) has been evolving over the past 15 – 20 years and is now becoming adopted by major organizations in the US, Australia, New Zealand, Italy and the U.K.

It shares little with TPM in tools, techniques and concepts. However, the biggest difference between to two models of project management is the underlying culture – values and behaviors – of APM.

The differences in values and behaviors between the two project management cultures are shown in Tables 1 and 2.

Traditional/Engineering PM Values	Key Behaviors
Closed	Project management is undertaken by experts who don't need input from "users". The project manager owns the project – the team, the budget, the scope and so on;
Distrust	Project team members and stakeholders need to be motivated, monitored and questioned at all times. If you don't monitor closely people will slack off. All estimates are padded and need to be "haggled" down;
Dishonesty	The true status of the project is to be "positively presented". Not asking for help is seen as strength and telling management want they want to hear is quietly encouraged. Projects are reported as "Green" or "Amber" and "Red" status is reported at the mast possible moment. Additional examples include inflating benefits and understating costs to ensure project gets approved;
Lack of courage	Not standing ground as professional, selling out the team and /or stakeholders by agreeing to unrealistic expectations (time, budget, scope, etc.), asking for help and assistance is a sign of weakness as is admitting uncertainty and mistakes;
"Technical fun"	The project is justified on the belief that great technology will automatically generate benefits. The more impressive the technology the most impressive the curriculum vitae. In addition, benefits belong to the "users" not the project manager.

Table 1 – Traditional project management values and behaviors


Again it is important for us to emphasize that these values are not deliberately adopted but, rather, are covertly introduced by the focus of Traditional Project Management on delivery rather than taking the whole-of-life perspective and by opening up the project to stakeholders.

Agile/Partnering PM Values	Key Behaviours
Open	Project management involves full participation and ownership by relevant stakeholders (including sponsors) not the project manager. The project manager owns the process not the project and its outputs and outcomes;
Trust	Project team members, sponsors and stakeholders are professionals. They can be trusted to work hard and be committed to the project and the organization. If trusted, they will personally commit to work as hard as required not to betray the trust given to them. They will be honest with estimates if given the chance;
Honesty	All people impacted by or involved in the project have a right to be told the truth and inflating benefits and under estimating costs is not acceptable. The right to say "I don’t know the true estimates, can I have some time" are seen as acceptable;
Courage	Undertaking projects requires courage in many areas - telling the truth, asking for assistance, admitting uncertainty and mistakes are signs of strength, acting as a professional;
Money	Projects consume shareholders, citizens' and corporate money and this requires a fiscal and ethical responsibility i.e. a duty of care to be shared by all team members, project manager, sponsor and stakeholders. Benefits realization is the responsibility of stakeholders but project managers must engage stakeholders and sponsor in ensuring that the benefits realization is planned and funded.

Table 2 – Agile project management values and behaviors


It has been a concern for our group that many of the proponents of the various Agile models either ignore or are ignorant of the cultural challenges associated with implementing Agile.

From assisting a number of leading organisations through the journey of implementing Agile, we have experienced first-hand how many people are confronted by the changes in roles and responsibilities demanded by the open and collaborative nature of Agile.

We explore the cultural impacts of Agile in other Blog entries and on our video series Agile Artisan in the Media section of this site.
by Rob on 1 Feb 2011

Spock's Law Redux

In another blog entry, Spock's Law, I talk about one of the key behaviours of an Agile project manager in using Spock’s Law "The needs of the one must not outweigh the needs of the many" to enable stakeholders to be openly and equitably involved in planning and other critical decisions in their project.

To effectively do this, the project manager will need to constantly manage the differing views of multiple stakeholders, to help them find consensus and to manage those stakeholders who attempt to "highjack" the democratic process. In less academic terms, to invoke Spock's Law.

However, just as in Star Trek: Genesis, where Kirk overrides Spock's Law to save Spock, there is one stakeholder who always has the right to override Spock’s Law.

The Sponsor!

One of the most important roles of an Agile project sponsor is to make decisions when the stakeholders' cannot.

For example, one of the key steps in planning a project using Rapid Planning sessions is to discuss and agree on the criteria for what constitutes a success for the project. Those of my readers who are familiar with our approach to Agile Project Management know that we use seven measures for project success.

These are:

• Degree or level of stakeholder satisfaction
This success measure determines which stakeholders must be satisfied at the end of the project and identify those who will be un-satisfied at the end.

• Meeting of objectives/requirements
These requirements deal with the business processes, data and documents that are the basis of the business or information system. Again, in most projects not all requirements need to be met for the project to be considered a success.

• Meeting budget
This is a relatively easy success criterion to understand. Budget includes people, equipment, accommodation and overhead costs. In some projects, the budget is completely fixed and, in others, the budget will be more flexible.

• Meeting deadlines
Again, this is an easy measure of success. The calendar tends to move one day each day. Like budget, this success measure has been used consistently in the past to measure and, in many cases, unfairly condemn projects as failures. Again, as in the case of budget, there will be projects where missing a deadline is critical. There will be many other projects where the deadline is flexible.

• Added value requirements
This criterion is probably the most important component of expectations. This measure focuses on whether the key drivers for the project are clearly financial (increased sales, reduced costs et al) or non-financial such as brand, customer satisfaction (though these could also be converted to financial benefits).

• Quality requirements
Quality requirements are often confused with functional requirements but quality cannot be modelled using standard systems modelling techniques. Quality requirements include attributes such as conformity (functionality), efficiency, reliability, maintainability, flexibility, portability, auditability, security, usability and reusability. Again, there can be very different for each project.

• Team satisfaction
This is without doubt, the most contentious of all the success criteria. This factor determines whether the team’s sense of satisfaction matters for the project. We accept that, in some projects, the other success factors may be more important than the team’s emotional state, however, we know that the decision to "sacrifice" the team must be made openly and at the start of the project.

So, it is very common when many stakeholders are involved in the open planning processes of APM, that there will be vey different expectations on quality, deadlines and so on. These are often resolved through more discussion and, if required, negotiation.

However, sometimes, someone has to make the call

It is NEVER the role of a project manager to over-ride stakeholders … however, the Sponsor owns his or her project and can follow Kirk’s revision of Spock’s Law.

This may not lead to another cool movie but it will set up the project for success.
by Rob on 27 Jan 2011

Can a project manager ask for help?

One of the most common topics that we discuss in our Agile Project Management workshops and during our consults is the topic of sponsors and their behaviour.

The typical comments include:

"My sponsor is too busy. She keeps cancelling our meetings."

"My sponsor just says JFDI (for those readers who do not know this acronym, it has something to do with Just F*****g Do It)."

"If I tell my sponsor the truth, he just yells at me."

A couple of years ago, my partner Camille gave me a present which was a book Why men can't ask for help and Why women can’t read maps by Alan Pease. I clearly have some "improvement opportunities".

To be honest, I read the book with a totally defensive attitude. "I did this. Once .. in 1982!" I would exclaim pointing at some accusation such as men not changing the toilet rolls which was contained in the book.

Reluctantly, I had to admit that asking for help was something that I wasn't very good at and, according to the book (and many discussions I have had on my workshops) so it is for most men (and project managers).

It has also become clear to me that many project managers suffer from the same psychological flaw.

I was talking with some very senior managers in one of my clients recently. I asked them how the new Agile model was working for them and one of them replied that it was going well and then asked me "What can we (sponsors) do to help?"

This offer of help really raised an interesting problem for me.

I had just had a mentoring session with one of the project managers who had the generous executive as a sponsor on a very difficult project.

The project manager had been complaining about the difficulty he was having getting access and attention from the executive.

I went back to talk with the project manager and he was very confused. "Look he said. Here is the meeting request in Outlook that he didn’t accept! See!"

I suggested the following and it has worked on a number of occasions.

You see a Meeting Request in Outlook is a Meeting Request. Plain and simple.

A Request for Help is a Request for Help. Plain and simple.

So we changed the Meeting Request in Outlook to a Request for Help and almost immediately the project manager’s mobile rang … it was his sponsor asking what he could do to help.

Perhaps all project managers should read Alan Pease’s book.
by Rob on 9 Jan 2011

Spock’s Law Version 1

There's a wonderful book called Everything I really need to learn in life I learnt from Star Trek by Dave Marianaccio.

Time and time again I am asked in workshops about the difficulty many project managers have in handling "difficult" stakeholders.

Often, like Dave ,when asked difficult questions I think to myself "What would Kirk or Spock say here?"

What I call Spock’s Law emerged at the wrenching end of "Star Trek II The Revenge of Khan". As usual the dual Hyperventilator (or some complex machine with an even more complex name was melting and the only way the ship and the crew could be saved from dicombulation was for someone to go into the engine room and physically remove some Aardvarker-pulsar thing. OK! Star Trek fans these are not the right terms, I know.

(In moments of sheer idiocies, I wonder if the writers who invented those wonderfully complex "technical jargon" terms for Star Trek bits moved into IT after the series was closed.)

Spock decided the logical thing was for him to go into the room and remove the aardvarker=pulsar .. the downside was that he would die via discombulation or something equally foul. Jim was, of course devastated and, in a scene as powerful as anything Igmar Bergman created (weeelll), Spock - being typically Vulcan i.e. logical - says

"The needs of the one must not outweigh the needs of the many"

and walks into the engine room, removes the aardvarker-pulsar, saves everyone, and with a hand moving slowly down the window … dies. The wailing of Star Trek fans could be heard around the world. Of course, fans know that he is re-generated in the next movie and Spock’s Law is reversed … hmmmm … see Spock’s Law Redux on this blog.

So here we have a project manager who is attempting to actively include critical stakeholders in the planning and owning of their project (welcome to Agile project management) and one person is behaving in a manner that is marginalizing or negating the power of many others.

Welcome to Spock’s Law.

Assuming all parties have an equal stake in the project, the project manager must confront (hopefully in a positive way) the person who is trying to negate the inclusive process. To give into one difficult person and alienate many other people you will need support from to deliver a successful project is not a good idea.

The very act of confrontation sends a number of positive messages. These include:

• The project manager is representing the whole stakeholder community;
• The project manager is prepared to be assertive for the good of the project and organisation;
• The project manager is prepared to deal with conflict in a positive way;
• The project manager has the requisite social intelligence; and
• He or she is someone to be trusted.

One of the core values of Agile project management is courage. Invoking Spock’s Law is a great example of this.
by Rob on 16 Dec 2010