One way to bridge the gap from raw requirements to user stories

I’ve been on two Agile projects now where the following has worked.  Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?

brainstorming-sessions

Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming.  They come out with a bunch of requirements.  They leave.  The dev team now has to figure out how to take this long list and turn it into develop-able requirements.  We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc.   But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project.  So here’s one way I’ve seen that works:

Assuming you’ve got that list of requirements I mentioned earlier:

Move requirements into Features

Raw

Analyze the requirements as follows:

  1. True Need Analysis – Figure out what the real requirement is behind the ask.  This is usually the domain of the BA. What is the user really asking for?  For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
  2. De-Duping and Current State-ing – Figure out what requirements are really mimics of each other.  For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible.   Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need.  So give the requirements a current state pass as well.
  3. Grouping and Aggregating – How do requirements  logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product?  Spend some time grouping those requirements together and give that feature a name.
  4. Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
You’ll come out with a not fully baked list of features which you can go take back to the stakeholders for verification.

Prep the Features in a Spike

Grouped

To fully Prep requirements, create a spike.

What is fully Prepped?  It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.

Handover the feature to the development team 

Usually this is accomplished through a separate spike meeting, with a presentation of the findings. Following the handover, the dev team should be able to breakdown the feature into epics and stories and the (currently well documented and doesn’t need to be rehashed here) Agile process takes place.
Cake
How are you handling this move from raw requirements into epics and stories? 

Prepping our Human Project Manager Selves for Crisis

A while back I wrote about the Project Management Institute’s 2011 Journal Paper of the Year by Manfred Saynisch.

“Here’s the deal – what Saynisch et. al. are proposing is a fundamental shift if the way we think about project management. We are moving from Project Management First Order to Project Management Second Order. And it’s all about the shifting collective beliefs…. Project Management theories and processes should start incorporating these ideas:

  • INSTABILITY IS TO BE EXPECTED
  • CRISIS IS AN EXPECTED OUTCOME
  • RAPID EVOLUTIONARY JUMPS PROVIDE A CHANCE TO EVOLVE TO A NEW LEVEL, EMPLOYING THE PRINCIPLE OF CHANCE”

As PMs we do expect a bit of progressive momentum on our projects, regardless of the method we choose. If we are in an iterative project, we expect progression to the plan. On agile projects we expect a certain rhythm; standups by day, planning, showcases and retros every few weeks.

 

But what happens if we accept Saynisch’s idea that we should accept that instability, crisis and rapid evolutionary jumps will occur, just when we least expect them?

Here’s the issue: we have the techniques and tools to plan for crisis (though I would argue most places don’t use them), but we don’t really talk about what our approach will be as Project Managers when control is seemingly lost. How do we, as people, make it through? How do we prepare our thinking for crisis? What expectations do we have about what we will or will not do during those times?

A Short Minor Crisis Story

I have one story, a positive one, about managing through minor crisis. As a program manager at a small company, I had been working hard to raise the level of project management maturity. With over 30 projects, we hadn’t connected projects to strategic programmatic goals and we had not prioritized the projects. People were going slightly nuts.

I (obviously) wanted to get a handle on this. Over time, I developed the relationships to have the senior leadership trust me enough to begin to work on these issues. After a number of months I was able to get all the execs in a room for a portfolio planning exercise.  And the goal was simply, place the projects into strategically aligned portfolios.

Within minutes it became apparent that my plan was going awry. The cool card sorting thing I envisioned was confusing people. And the discussions were moving away from the topics I wanted. And I thought ‘ dammit, I’m about to lose a golden opportunity’. The execs started questioning why there were there. Schmuckers!

But..I had done my research. And I knew where the problems lie and I started to honestly communicate. I admitted immediately that the method I had envisioned to solve the problems had gone a little nutso, but reiterated that we could still solve the problems we faced. Then there was discussion amongst them, and I sat back and let it unfold. Which was hard. I didn’t know where it was going. But the problems we faced had been laid out before us, and we all knew we had to solve them. And then, like instant magic, they decided, en masse, that instead of portfolio planning, they were going to prioritize projects.

And I was like ‘Booyah!!’. That was better than I could even have hoped.  My original plan got thrown out the window (thank God), and during the turbulence between the old plan and the new, the things that helped me keep up forward momentum were:

  • the relationships of trust I had with the team (they’re thinking “Michiko’s not an idiot, so I think we must be here for some good reason”),
  • the knowledge I had (I’m saying “Hey folks, we have some serious issues to solve here; here’s example 1, and here’s example 2”), and
  • it was ok to abandon the method to move forward (“well, looks like the card sorting exercise is a bust, but what can we do to solve our problem”).

And the outcome was fabulous.

It could have gone something like this: I keep trying insanely to stick to a method that obviously was not working, I shut down. I say something like ‘ok, we’ll pick up at some other time.’ They then lose faith in me, I lose some cred. We stop moving forward.

Preparing our Human Project Manager Selves

Saynisch’s model says that we should expect crisis, and out of crisis we will experience evolutionary jumps. I think the implication of that model is that we need to plan and prepare our personal response to crisis.

In other words, what are we thinking when the you-know-what hits the fan?  How do we manage ourselves well, so that we have the right expectations and subsequently help to manage others well?  What do we hold onto and what do we let go to make it through?

What I’m suggesting is that shifting our paradigm to expect crisis also involves shifting our approach to project management during these times of crisis. I thought I would share with you some of my own learning from crisis periods, and how I’ve adjusted my approach to fit those crazy times.

So here are three things that I think happen during crisis and three changes in thinking that I think may help you prepare and manage through crisis.

In crisis, trust relationships trump authority

Trusted enough to run a movement from jail. Master of relationships.

Crisis represents the breakdown in normalcy. And during crisis the normal reporting relationships and hierarchies will not be as important as who people actually trust. In crisis, people will follow who they trust.

Implication: If you want to lead through crisis, develop relationships of trust.

Build your relationships. Work to appreciate people and what they do. If you have beef with people, try to work it out. Make sure you know the names of everyone on the project and understand what they do and how. Take time to talk to people about life in general. Revisit your own methods, see where you can adjust if you have an area that needs work. Read a self-improvement book. Read books about team building.

This Guy (the one standing up)! Knows everything. And no one follows him UNTIL the crisis.

In crisis, knowledge trumps authority

Similarly, people will most likely follow those who know how to get out the crisis, not the stated authority figure.

Implication: If you want to lead through crisis, keep learning; fill yourself up with knowledge. The more you know, the more you’ll be able to quickly connect the dots to develop a plan for getting out of the crisis.

During times of normalcy, become knowledgeable about everything related to your project; how the enterprise works, what systems do what, how communications occur. Most importantly know the intimate details of your project. Read the requirements, read the test scripts, understand the business benefits and know why the enterprise needs to achieve them.

In crisis, forward momentum is more important than method

Turns the method on and off as needed.

During crisis, Its more important that group feels that they are somehow making progress rather than that they are following the norms and rules of methodology.

Implication: Be willing to abandon the method, in favor of forward momentum. And then communicate like crazy, all the time. Because method is really about communication. And you’ll have to pick up that slack.

Be hard on yourself about communication. Make sure everyone knows as much as they can. Walk around. Tell people. Email. Post it on Yammer. Use every form of communication you can to tell people what’s going on.

Avoiding the Shutdown

Here’s what some people do in chaos: Shut down. Stop communicating.

Why? Because they don’t have the knowledge, they don’t have the relationships and they realize that without both they won’t be able to do the communication necessary to keep forward momentum going. And they know that as soon as they start speaking people will realize it. And in extremely chaotic situations, people will stop following them and follow the person who does have the relationships and the knowledge.

Let’s prep ourselves to avoid the shutdown.

Talk Back

So these are just a few ideas to start the shift in thinking. What do you think? What crisis experiences have you had to manage through and what did you learn?

One Small Thing

Today I’m inspired by Richard Branson, founder of Virgin Airways.

In providing his best tips for starting a successful business his number 2 is,  “Keep it Simple”. He says

“You have to do something radically different to stand out in business. But nobody ever said different has to be complex. There are thousands of simple business solutions to problems out there, just waiting to be solved by the next big thing in business. Maintain a focus upon innovation, but don’t try to reinvent the wheel. A simple change for the better is far more effective than five complicated changes for the worse.”

A simple change for the better is far more effective than five complicated changes for the worse. – Richard Branson

Have you ever been on a project where things changed massively all at once?   Sometimes the change is necessary but there’s no denying it wrecks havoc on relationships.    I’ve been that PM in the past, the one who wanted it all to go by the book; the perfect project plan, absolutely correct adherence to the SDLC (whichever method we chose) .. and I would push really hard, early on.  And wind up being the one who bought in ‘five complicated changes’ that inevitably made things worse.

And it wasn’t methodologically worse; it was relationship worse.   The changes were so sudden, they pushed people immediately into taking sides.  People never got to really know me as a person, I just became that PM, the one pushing everyone’s buttons the wrong way.  I hadn’t learned this truism that really…

…One simple change for the better would have been far better than the perfect methodology (and the 5 changes that came with it).

Now, I’m a little bit more relaxed.  I see things every day that I wish I could change, or hear things that make the SDLC-lover inside me want to run for the hills.  But…its one thing at a time.  Crawl.Walk.Run.  I’m focusing my energy first, on appreciating what people are doing, rather than trying to analyze them against a methodology checklist.  Second, I’m looking for that simple change that will make things better for everyone.

Here’s one idea from the most recent PM Network  A PMO in Kentucky doesn’t force low probability risks into the risk management process.  “ ‘We make note of it and discuss it informally.’ Says Janice Weaver, associate vice president of the EPMO at Norton Healthcare. ‘But we don’t spend hours on tasks that don’t add value to our process.’ “

What’s one small thing could you do on your project that would make things better?

Here’s two guys who’ve mastered simple play Simple Gifts..wouldn’t it be awesome to feel like this at work!

 

Help I’ve Lost My Measurable Benefits (and I Can’t Get Up)

I had to get myself unstuck recently and I thought I’d share with you what I’ve learned.

Help! I’ve lost my measurable benefits (and I can’t get up)

My problem is that pre-project measurement and analysis time is a virtual luxury for small and medium sized firms given the highly competitive environment we are in.  And so many projects begin with more intangible, unmeasurable goals than tangible measurable goals.  Which means that while success can be obviously felt, seen, touched;  it can be hard to prove.

It would be nice to get, for example,  ‘approximate processing time for purchase order task completion’ baseline measurements before starting a project.  But  it’s kind of hard to do when the users sound a little like this: “OMG IF I HAVE TO FREEKIN PUSH ANOTHER FREEKIN BUTTON TO FIX THIS DAGGONE PURCHASE ORDER I’M GOING TO THROW THIS COMPUTER OUT THE WINDOW”

Upon which, the system/powers that be say – OK, let’s move forward with a new system.

And then the PM is now writing up a project charter for the project to get a new system and runs into ‘what are the benefits/capabilities’ to be gained in this system to which they say something like ‘improved productivity’.

But there’s no baseline measure, and so this basic benefit, something really super important to the success of the project, usually remains intangible; something that is felt rather than measured, perceived rather than calculated.

A Program Manager’s Greatest Fear

That’s where I’m stuck. Because as the Program Manager I’m telling the PMs, ‘the project will be evaluated by the realized benefits’, and the PMs are saying ‘but the benefit is unmeasurable.’ (which in actuality really means, we don’t have time to do an analysis phase on this thing, we just have to fix the problem).

As an aside, there is growing support for methods used in identifying and tracking benefits. Collectively this body of work is operating under the coinage ‘benefits realization’. I’m incorporating benefits realization into our process. See Thrope ‘The Information Paradox – Realizing the Business Benefits of Information Technology’. And see the Benefits Management process in the most recent Practice Standard for Program Management.

So the question is: Is an unmeasurable/intangible benefit ok to use as project evaluative criteria?

I think the answer is Yes and No.

No in that while we may not be starting with a baseline to compare to for measurable benefits, that doesn’t mean we can’t still define a goal and measure that goal. I think we have to have some type of measurement of benefit or intended outcome for every project.

Yes in that we should strive to be very clear about the intangibles. Even if we can’t measure them, we need to acknowledge them, list them out, clearly state them. The intangibles provide the nuances that can make or break success. For example, I want a car that gets 35 MPG (tangible), but it also has to be cool (intangible).

So the challenge then is how to help project managers identify measurable (tangible) benefits and unmeasurable (intangible) benefits such that even if we don’t have a measurement baseline to jump from, we can at least find some definable goals to reach for, with intangible descriptions to shore up the tangibles.

Here are some helpful things I’ve found to do so.

Clarity on intangible versus tangible

In their book Enterprise Programme Management, Williams and Parr assist with this definition:

“Benefits fall into three categories:

direct financial benefits: those that can be quantified and valued (tangible)
direct non-financial benefits: those that can be quantified, but are difficult or impossible to value (tangible)
indirect benefits: those that can be identified but cannot easily be quantified (intangible).”

Some Tangible Benefits Examples:

  • Cost Avoidance
  • New Income
  • Additional Income
  • Reduced Working Capital

Some Intangible Benefit Examples

  • Strategic Alignment
  • Competitive advantage
  • Competitive response
  • Improved customer service
  • Kick Butt Communications (from my company ;) )

For tangibles, use precise measurement terms

Thorpe suggests using his MEDIC acronym to derive precise language to describe benefits. Instead of ‘effective’ or ‘better’ use terms like ‘maintain’ or ‘increase’.

  • M: Maintain – e.g. a level of service maintained
  • E: Eliminate – e.g.a function eliminated
  • D: Decrease – e.g. turnarond time decreased
  • I: Increase – e.g. revenue increased
  • C: Create – e.g. a certain capability created

From Information Systems Evaluation Management by Wim Van Grembergen

Finally, we can give easy benefits examples, perhaps in a ‘benefits list’ document.

Here are some examples I’ve found in the field:

I can say that all the projects we’ve done in the past year have had efficiency, productivity, and regulatory expected outcomes, even though we may not have measured where we started from at the beginning. We are now seeing those outcomes come to fruition; as well as perhaps the one intangible that I like but that rarely gets written in a project charter; a happier work environment.

Fundamentally though, I think we still need clearer direction on how to identify benefits.  We’ve got good processes for managing benefits, but I would love to see more easily accessible guidance on benefits identification.

Speed it Up: Release the Ownership of Making Changes

Looking for ways to speed up operations on your project?

Think about Releasing the Ownership of Making Changes.

On many processes, there is a Process Owner and the definition of ownership for that process owner includes:

  • Ownership of Making Changes
  • Ownership of Implementing Changes

Ownership of Making Changes is when the process owner must approve a change before its made.

Ownership of Implementing Changes is when the process owner must approve the change before it’s implemented.

The problem with the Ownership of Making Changes is that it takes longer for changes to happen.

Longest Process

The usual flow is:

Someone (let’s call her the Change Agent) recognizes a need for change

  • The Change Agent preps a request to Make the Change to the Process Owner
  • The Process Owner gives approval to Make the Change
  • The Change Agent Makes the Change, along with all the other stuff she’s got to do
  • The Change Agent preps the final change for approval
  • The Process Owner gives final approval for the Change Implementation

Ok so, what if we pulled out the need for approval to Make the Change? We’d lose a bunch of steps and gain more time.

Shorter Process - Ownership for Making Changes has been released

That flow would look like:

  • The Change Agent recognizes a need for change
  • The Change Agent Makes the Change, along with all the other stuff she’s got to do
  • The Change Agent preps the final change for approval
  • The Process Owner gives final approval for Change Implementation

Now…you can really speed things up by training a group of people to do the work, so that anyone can make the change. If you encourage Change Agents to communicate the recognized need for change transparently, maybe through a collaborative system, then any one of the group can pick up the change and make the change. Assuming that the person who picks up the change did so because they don’t have any other work, they don’t have to shuffle it in priority with other things on their plate. So the work gets done faster.

That flow looks like this:

Shortest Process - Many Trained People Can Do the Work

This idea is why Kanban and Agile teams get things done faster.

The Big Picture of Time Savings by Removing the Ownership of Making Changes

Implementation Guidelines

To really make this work, the Change Agents must be people with the skills and training to make the changes. Ensuring that you have a key skilled group of people provides a measure of confidence to Process Owners and prevents chaos when making change.

The Process Owner must still approve the change, which also prevents chaos. You should also create some type of way to rollback if the change is not approved or a place to make visible and shareable drafts.

Try this on a small process and feel it out. You may find that Removing the Ownership of Making Changes results in large, beneficial gains in productivity.

Influence Not Control; The New Project Manager Role

I believe that in a few years time, the Project Manager as we know it, will go away. There will be hold outs in slowly changing industries (defense for example), but on the front edge of the economy, in the newer industries, the Project Manager is going away.

This is something to take note of – it doesn’t mean that we Project Managers will no longer be useful. It means that in order to hold our jobs, we have to adjust our thinking, our paradigms, about our role in relation to others and about the value-add we bring to any organization.

Manfred Saynisch’s article in the PM Journal talks in detail about this upcoming shift.

I’m starting to see things differently because of it. I’m starting to see my role differently because of it.

This is a long post. For those who don’t want to read, I’ve summarized in these bullet points:

  1. Traditional project management methods are failing due to the complexity of the systems in which projects find themselves.
  2. To be successful, Project Managers should start to adapt to complex systems; moving from controlling to influencing.
  3. This is a difficult, but necessary change and expansion of the Project Management role.

Traditional Project Management Vs. Complexity

Manfred Saynisch is the key author of Project Management Second Order (PM-2), a new framework of thinking about Project Management that was published in the Project Management Journal in December 2010.

Saynisch explains that projects are goal oriented endeavors that operate in a context of larger self-organizing, evolutionary systems. These larger systems are evolving at their own pace.

For example, a small company (the ‘system’) progresses towards its goal at a pace that’s influenced by many causes, both internal and external. The pace resembles evolution, with gradual growth, occasional shocks that send it shooting off in one direction or another. A complicated network of interrelationships influence this context, and put the stops on it, or send it careening forward. Different entities within the organization have different stocks* of power and energy and thus the company organizes, and then re-organizes (self-organization) based on all these things. Predicability, even in smaller companies, is really difficult.

Intense Organizational Complexity - the Army Force Management Model - Click for details

Enter the Project Manager who has been taught to develop a schedule, to control all the internal and external forces, or at least manage them so that the goal can be reached.

Our methods usually employ single cause controls (such as controlling for individual risks and issues, or stakeholders), and assume a linear time progression to the project which we capture in a schedule. We seek to aggregate the amount of time it will take to accomplish tasks, so we can estimate finish times, and to start and stop the processes just when we need them to. The methods operating in the project are a far far cry from those operating in the system that the project finds itself in!

Inevitably, we bump against the self-organization evolutionary methods that exist in the system.

We call them corporate politics, or the market, or commodity prices, or new home starts, or consumer confidence and we evaluate who has certain stocks of one thing or the other – who has influence and power, for example, in order to try and control how the system affects our projects.

Sometimes we are successful. A lot of times, we fail. We fail because the system is moving at a rate that doesn’t work for our project, the self-organizing, networked, multi-causal system will not bend to controlled methods, such as schedule management, issue management or stakeholder management; methods that evaluate single objects and seek to influence those objects independently, without analysis of the many many environmental influences that object is subjected to in the system.

Brand New Worlds

Yes – its complicated. Actually – it’s complex.

The New PM Worlds

Saynisch’s model introduces a new way of thinking about Project Management. He is suggesting that the way in which we currently manage projects, which he calls PM World 1, Traditional Project Management, is characterized by the following:

  • A Project Manager external to the system
  • A Project Manager seeking to implement controls on the system
  • A sense that there is a linear, logical progression to events
  • A sense that objects in the system can be controlled through various methods
  • A belief that there is usually one cause, and therefore one effect. Control the cause, and you control the effect.

World 2 is about acknowledging and understanding the complexity of systems. He calls this world ‘Complexity Management’. World 2 is characterized by the following:

  • A Project Manager who is inside the system
  • A Project Manager who influences the system, rather than controls the system
  • A sense that events are evolutionary and non-linear
  • A sense that objects in the system have their own flow and organize themselves
  • A belief that there are multiple causes and therefore multiple effects. And that you cannot control most of it.

The future, Saynisch indicates, is in the ability to develop processes that mimic the self-organizational, multi-causal flow of complex systems while simultaneously accomplishing the goals of the project. Its about encouraging the development of patterns and self-organized structure, gently nudging the system toward the goal, rather than enforcing rules and applying structure.

We must migrate from EXTERNAL CONTROLLER OF EVENTS to INTERNAL INFLUENCER OF PROCESS

Saynisch also proposes 2 other PM worlds. World 3 – The universe of Human Behavior and World 4 – The universe of Ground Rules and Ways of Thinking. These are important to explore as well, but I’ll save that for another post.

World 1, Traditional Project Management, doesn’t go away in this new model. Instead, World 1 provides the description of the system. Traditional Project Management is like the glossary where you learn; what is a Stakeholder, what are Activities and how do they work together, what is a Risk. Traditional Project Management knowledge is also a how-to manual and toolkit that are used to influence the system. Traditional Project Management provides the tools and knowledge to know how to build the processes.

And World 2, Complexity Management, encourages the PM to think about building self-sustaining systems and processes, where people are provided the tools for self-management, where actors are taught to reference principles for self-guided behavior, and where processes are networked intelligently to produce desired outcomes.

He writes “Finding the proper balance between complexity and traditional management will be the future management art.” page 8 Project Management Journal, December 2010

Finding that balance is more than just a bit hard. Its daggone difficult. But, and this is why I’m even writing this post, I think it’s the only way to build really good projects that work in the future.

The new PM must phase out control, and increase influence

The difficulty comes in on a personal level. When you are used to acting externally on a system, when you are used to the control role, letting go of it can seem like a career killer. The difficulty also comes in on a method level. In this new view the methods that are the most important; the ability to influence, the ability to strategize, the ability to think in systems, the ability to encourage the adoption of principles in others, seem nebulous. Where do you learn that?

And not only is this difficult, there’s indication that Its also the way to keep your job.

I don’t know about you, but this article Google Facing a Significant Reorg with Managers on the Firing Line scared me. It read to me like Google was eliminating pure Project Managers and indicating that they had built internal self-sustaining structures and principles such that people managed themselves.

“Google will be moving away from a structure with centralized managers and towards a structure where engineers run individual units.”

Witness as well, the rise of Agile, where the PM provides influence and direction from inside the system. The team decides the schedule, and that schedule is not wholly predictable from iteration to iteration. Agile has built in acknowledgement of the multi-causal, dynamic, non-linear system. Or Kanban, where teams of people set up systems that reveal bottlenecks and are encouraged to solve them together as a team. No pushy PM needed.

Maybe this is why Forrester analysts are suggesting that the “Next Generation” Project Manager have both World 1 and World 2 skills.

Mary Gerush writes “Next-generation project managers still have a sound understanding of project management best practices (pm world 1), but they also have updated soft skills focused heavily on people, team building, and collaboration, and they understand how and when to adapt processes, practices, and communications based on context (other PM Worlds) Mary Gerush, Forrester, Define, Hire, And Develop Your Next-Generation Project Managers

emphasis mine

You may be saying to yourself ‘What’s the big deal, soft skills have always been a part of Project Management?” What’s different is that this is not just about soft skills (as in getting along with people), but about migrating from external controller of events to internal influencer of process “based on context”.

Does the Google example indicate what’s valuable on the market? I think so and I think it’s this.

In the new world, the ability to influence a self-organizing system to move in a more effective, productive manner is more valued than the ability to bring in projects on time and under budget.

Influence not control. It’s about understanding that your goal is to apply what you’ve learned in your PM toolkit towards the development of processes that both incorporate good PM methods, but also can sustain themselves without you.

For example, instead of building a change management process that starts with a change management plan leading to a weekly meeting of a change control board, you instead seek to define the effects that certain changes will have on the system. You then train the team to recognize these effects so that they know a change is needed. You then encourage them to decide on changes based on the principles you’ve taught.

In this example, Traditional Project Management tells you that changes should be managed. That’s the influence of World 1. Then in a very World 2 type of way, you build a process that communicates the ‘why’, that teaches change management principles to the actors in the system, and then allows the system, the teams, to self-organize and decide on how to use the principles. It’s expected that in this new milieu the original principles will evolve. So what you’ve really added in then, is the thought ‘changes should be managed’, which derives from World 1. But you’ve released the ‘how’ to the system and by release, you also allow the idea to evolve to what the system can handle and resolve.

For anyone who plays the game Osmos on the Ipad, you can see this in action. The balls move in a complicated dance and you, the player, are the nudger in the system. You are trying to reach a goal and the only way you can succeed is to gently nudge and push objects that are already moving. This game is not about lining up the balls in an assembly line – its about observing the system and knowing how hard and how long to push.

Take a minute to watch the Osmos video to see what I mean.

So..next steps

Think About It

I think it’s important to give this some thought. Figure out what skills you bring with you from World 1 and then think about where and how you’ve practiced World 2 skills. Think about those times when projects have gone completely off the rails and what skills you used to bring them back in. Think about the processes you built to prevent that from happening again. Think about the teams you’ve mentored to do great things, and how you influenced them, and what remained, what was sustained after you left the project.

Within this thought process, you’ll start to find your skill set, those areas where you are strong. You might then start to focus on those areas in preparation for shifts in expectations about your role that I believe are sure to occur.

* For more on Systems and stocks, read Donella Meadows Thinking in Systems: A Primer