Loving the Devs OR A Little Appreciation and Trust Goes a Long Way

Developers get a bad rap from us IT PMs.

We IT PMs have a sort of prevailing wisdom about dealing with the ‘devs’. We even talk about it in our job interviews as a known issue; this idea that Devs are cantankerous arrogant curmudgeons, and we need to have certain skills as PMs to navigate through Dev incurred roadblocks to timelines.

Well, I’ve worked with and been friends with Devs for a long time and I think it’s time we think a bit differently about them. From what I’ve seen, Devs have always been good to me (made deadlines, stuck to process, built incredible things) when I’ve thought of them, and given them high regard.

I think any PM will see an improvement in Dev-Pm relations if you remember and adapt to the following:

Appreciate The Knowledge

Requirements become design and merge with the human skill of the builder/artisan to become something usable and beautiful

Developers are  like skilled artisans; people who shape, and mold an idea into something concrete, movable, usable. We respect someone who, for example, builds a beautiful table, because we understand that the ability to merge art and function is unique and rare. Perhaps because there is so much work, and so many developers, we tend to down play the work they actually do.

With an artisan point of view, we should approach developers with an appreciation for their knowledge. This attitude manifests itself when we interpret questions around requirements not as stone walling, but instead, a desire to build the best thing possible.

Artisans tend to develop a sense of pride in their creation. We should recognize that when we shift gears too suddenly in requirements, that thing in which pride was taken, has to be tabled. There is some kind of human cost to this, a disappointment. Multiple disappointments can lead to bitterness. As PMs we should recognize this sensitivity. Our role in controlling the process and QAing and ensuring good requirements is key to minimizing this phenomena.

Trust the Delivery

I approach that edge of the full elaboration of requirements and the beginning of the magical transformation into something functional carefully.   As a team, we want to explain the design, but relax and step back slightly to allow the technical ability to form idea into function to show itself and flourish.

I think a lot of PMs have a hard time letting go at this point. We often want to know the exact details of how something will be built. So we have to employ trust and allow the development team to prove that they can deliver. Paradoxically employing trust, even if things arrive a little late, serves to open up the channels of communication about the details.

It’s ok…let go!

I learned this directly from a dev manager when he suggested that instead of questioning why something was done by a certain date, I instead inquire about the complexity of an item. The implication of ‘is this more complex than originally thought’ is that the developer is doing their job. The implication of ‘why isn’t this done’ is that the developer is not doing their job. Subtly of approach respects the individual and lends towards a better delivery.

Give em a say in the Process

Contrary to popular belief, I think most developers actually like process. I’ve worked with dev teams who’ve initially resisted process become dev teams who champion process. The win for the developer is when process produces good requirements, be they requirements documents, or super clear user stories with well thought out acceptance criteria. The other win for process is when the process keeps WIP at some kind of sanity level to allows the developer to do the kind of work they take pride in, and the team to trust the delivery. Monitoring both – clear requirements and scope sanity – will be an immediate win to reducing barriers to process.

Especially when it comes to code migration process, we can really engage developers. Let them create the process while providing guidance that the process should be simple, clear, clearly elaborate roles and serves to ensure traceability. PMs can help by then documenting what the developers agreed to, helping to shore up any holes in the process, and then acting as an oversight on that process. The key is it’s their process, not something that was dropped on top of them.

Course, those three things, appreciation,  trust and communication are the basis of all good human interaction.  PMs, let’s do what we can to make sure that when it comes to developers, we employ these tools to become partners, not antagonists.



Are you an IT Adviser PM or an IT Push-Backer PM

Today I’m inspired by Andrea Brockmeier and Elizabeth’s Larson’s article in Project Times concerning 2013 Trends in Project Management. 

Number one on their list is that project professionals need to provide advice, not push back.ProjTimes

“Project professionals need to provide advice, not pushback. Several years ago organizations told us that they wanted PMs and BAs to be able to push back when their stakeholders asked for new requirements. Some of these organizations are now seeing that pushing back is one way to avoid being an order-taker, but it is less effective than providing well-analyzed advice. Our prediction is that more organizations will want PMs and BAs to be trusted advisers (sometimes called trusted partners).” from http://www.projecttimes.com/elizabeth-larson/2013-trends-in-business-analysis-and-project-management.html

I would just like to add on to this idea.

Over the past couple of years, I’ve run into Project Managers who are expert Push-Backers.  I think a lot of them don’t really know what advice giving really looks and feels like.  I think that they are so used to being ‘IT’ that they adopt push back as part of the culture.  I have at times been a push-backer but fortunately I’ve had really painful experiences that have forced me to be more of an adviser.  So having sat on both sides of the fence I decided to write up a few things that indicate to me what an adviser looks/sounds like vis what a push-backer looks/sounds like.

Here we go:

Investment in the Solution

The IT Adviser PM:

You’re not really that invested in the solutions proposed.   You care, because you want the best thing for the project, but if the wrong decision is made, you feel that you’ve given it your best shot and that’s it.  You recognize that giving all the info was your role, the decision was not your role.

The IT Push Backer PM:

You are absolutely invested in the solution you’ve presented.  You feel emotionally distraught if things don’t go the way think they should.   You think any decision that is different from the one you’ve already made in your head is wrong.

Collaboration on SolutionsPushback

The IT Adviser PM:

When you  listen to solutions or directions other than your own, you really listen. You’re open, you consider, and you build on what you’ve heard.

The IT Push Backer PM:

When other people give their ideas, you look for ways that those solutions won’t work.  You are vocal about how those solutions won’t work.

Respecting Others Knowledge

The IT Adviser PM:

You think that business people, even though they aren’t as knowledgeable about systems as you, should be given respect for what they know about their business domain.  There are things you recognize you don’t know, and you are open to learning.

The IT Push Backer PM:

You think that business users should pretty much stay out of systems.  You know the system, you know how it works, and they don’t need to know too much about how things work.  Business knowledge is important, but only to the extent that it results in good requirements/user stories.

Advisers listen and assist

Advisers listen and assist

Risk Mitigation:

The IT Adviser PM:

You think about what could go wrong because you want to make sure that the solution succeeds.  You bring it up and talk proactively about risks, and  you give business users a way to discuss risk without it being personal.

The IT Push Backer PM:

You think about the solution as an IT solution.  Anything that happens outside of IT must be resolved by business users.   One major risk that you see is the business not having their act together and wasting your people’s time.   You actively guard against this risk.


So which one are you?  Chances are you’re a little bit of both. Chances are you have to shift between a continuum that has adviser on one side and push backer on the other depending on who you’re dealing with.   But if we are to look at the trends, as suggested by Brockmeier and Larson,  it can’t hurt to take a personal time out and think about how you can develop some refined adviser chops for the future.

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:


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?

Removing Soft Skills stigma; a good book and a suggestion for PMI

We all know/have heard how important soft skills are to our success in Project Management.

Some of us are getting tested to see where we’re weak or strong, some of us have joined conflict management groups, or are taking self-help courses in leadership and team building.

But for me, it all still seems a little disjointed.

I mean, it’s really clear what you have to do when you need to, for example, bone up on your earned value metrics. You take an assessment to see where you are. There are seminars, online classes, workshops-at-sea, books, a nice chapter in the PMBOK etc.

Same for Risk Management or some other tangible hard skill that we need to learn.

And there’s not a lot of stigma with needing to bone up on hard skills either.

Oh God! Starfleet says I have to work on my soft skills

So I’m at a PMI conference and I turn to my neighbor and say, “Ugh, I have to take the EVM seminar. I’m soooo bad at it,” and I get a hearty warm response. “Me too!” and we go on lolly gaggin about EVM. I’ve made a friend, it’s all great.

Same scenario but instead I turn to my neighbor and say, “Ugh, I have to take the Self-Awareness seminar. I’m soooo bad it.” And I get a concerned look, “Hmmmm”, as if I’ve just admitted I drink a bottle of wine every night.

First of all, I don’t think I’d admit my soft skills ‘issues’ to a stranger and secondly, admitting it almost sounds like I need a therapy session!

So addressing soft skills is a bit harder. There is some type of stigma attached to not having certain skills – it gets more personal. Also, soft skills are really hard to pin down. For example, I may know that I’m bad at leadership from feedback I get from my team, but like, what part of leadership?!

I search online for the ‘leadership skills’ assessment. You know, like the one I took that told me I needed to learn EVM. Nothing.

I pour over my emails. Was it something I wrote?
I revisit meeting notes. Did I slam somebody?

I finally ask a colleague and they say, “It was your emotional control.” Ohhhhhh, my emotional controooolllll.

Where do I go to deal with that? Can I look up ‘controlling emotions’ in the PMBOK and read up on how to improve, or take a controlling emotions seminar-at-sea (well probably), but you get my drift. It’s harder to address soft skills.

So that’s why I was so happy to meet Deb Herting at UPenn yesterday. Deb is a PMP and CEO of The Deborah Group. She was giving a talk on her new book at the Penn Bookstore.

Her book is called The power of Interpersonal Skills in Project Management and I see it beginning to solve part of the problem of addressing soft skills.

First, its an easy read, not intimidating, less than 90 pages book. That’s something you could give to your boss with a subtle wink, and they might actually read it.

Second, and most importantly, Deb has provided a framework for soft skills that helps identify and organize skills into a manageable lists.

Something about the framework and the organization makes the soft skill more tangible for me. Maybe it’s the fact that PMI’s list of ‘interpersonal’ skills is long and vague. (see the appendix of PMBOK 4th ed.)

But her list has only three interpersonal skills, those she considers to be the most important from PMI’s list; Team Building, Leadership, Communication – with a handy acronym; TLC.

And within each, there are abilities and competencies that are easy to grasp.

So instead of pouring through emails to figure out where I suck at leadership, I can do this.

Really? I don't set Clear Goals and Objectives? But what do I do? Where do I go? (wahhhhhhhh)

My co-worker says, “Michiko, you suck at leadership”.

After I go to the bathroom and cry, I come back to my desk with a mascara streaked face, and pick up ‘The Power of Interpersonal Skills in Project Management’.

‘Hmmmm’, I wonder, ‘Where am I bad at leadership?’.

And I can ponder from a whole list of leadership skills Deb has provided in her framework such as:

  • Be Passionate
  • Be Self-Aware
  • Control Emotions
  • Manage Expectations
  • and many more….

So the nebulous (‘I suck at leadership’) has become the concrete (‘I don’t think i’m controlling my emotions’.)

We all need this – this next step to understanding how to improve our soft skills. We need a breakdown, we need a way to make it tangible, and manageable.  Currently, soft skills guidance is nebulous and scary, PMI should work on making it concrete and universal, thereby removing any associated stigmas.

Deb’s book begins to do that.

I think next steps are for PMI to do the same, to incorporate a whole chapter on soft skills, not just an appendix. Give concrete, tangible areas to improve. So instead of a paragraph called ‘Communication’, give a breakdown of skills under communication and describe what they are, just like Deb has done.

And then start to encourage providers to test PMs on those skill sets and  PMPs to receive training on areas to improve.  You can look at The Deborah Groups one day seminar “The Socially Emerging  Manager – Interpersonal  Skills for the 21st Century Manager” as a great of example of how to do just that.

So then, the next time I’m at the PMI conference I turn to my neighbor and say, “Hey, I’m taking the ‘Controlling Emotions’ seminar”.

My neighbor says, “Oh yeah, I took that online test too, and I really have to work on ‘setting clearing goals and objectives” and we start lolly gaggin and having a great time.

There’s not so much stigma because PMI would’ve have openly identified skill sets where people need to improve and everybody will have something to improve on that list (not just old mascara face over here).

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.


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

Stanford’s 10 Good Ways to Change Behavior

This one really got me thinking.

I follow the US Army Comprehensive Solider Fitness program on Facebook.  They’re all about positive response to traumatic occurrences, where trauma leads to strength and resiliency rather than continued pain and failure.  You can read more about CSF here.

Today they posted the following presentation from Stanford University’s Persuasive Tech Lab: The Top 10 Mistakes in Behavior Change.  For those of us working change management as Project Managers (which is most of us) I found these ideas to be a bit challenging, but in a good maybe-I-should-adjust way.

View more presentations from Persuasive Technology Lab at Stanford.

Here they are:

The Top 10 Mistakes in Behavior Change

1. Relying on willpower for long-term change. Instead,imagine willpower doesn’t exist. That’s step 1 to a better future.

2. Attempting big leaps  instead of baby steps. Instead, seek tiny successes –one after another.

3. Ignoring how environment shapes behaviors. Instead, change your context and you change your life.

4. Trying to stop old behaviors instead of creating new ones.  Instead, focus on action, not avoidance.

5. Blaming Failures on lack of motivation.  Instead, make the behavior easier to do.

6. Underestimating the power of triggers.  Instead, [understand that] no behavior happens without a trigger.

7. Believing that information leads to action. Instead, [understand that] we humans aren’t so rational.

8. Focusing on abstract goals more than concrete behaviors.  Abstract: Get in Shape. Concrete: Walk 15 min. today.

9. Seeking to change a behavior forever, not for a short time. Instead [understand that] a fixed period works better than ‘forever’.

10. Assuming that behavior change is difficult.  Instead, [understand that] Behavior change is not so hard when you have the right process

I always get caught on number 7 Believing that information leads to action.  I tend to think that if people know about consequences of their actions, they’ll make adjustments.  One would think that, for example, if you’re the belly button to the health of the US economy, and you know that you don’t know the credit profile of your billion dollar book of business, you’d stop and re-assess and maybe add more credit enhancement.  But, that’s not what Fannie Mae did.  The rest is history and it’s definitely not rational.

And how many times have we blamed a failed process on people not performing needed steps in that process.  Our Risk Management process doesn’t get off the Risk Management Plan paper because everyone skirts around it; and nobody likes the idea of a risk owner.  Maybe this is what number 5 Blaming failures on lack of motivation is about. Maybe the process is too hard and we’ve got to ‘make the behavior easier to do‘ if we really want to implement our process.

Stanford’s got some pretty cool stuff. Here’s a new field – Captology  – Computers As Persuasive Technologies ‘capt’ and ‘ology’.  I’m sure it’s a play on words with ‘captivate’.  I can honestly say that if I use a website that captivates me, keeps my attention and engenders wonder, I’m really open to whatever is being sold.  Check it out – more on Human Computer Interaction (HCI) and using programming to persuade on Stanford’s Captology Website.

Cutting Through Bias – Two Ways to Psych your Team into Winning

This may sound a bit simplistic. But maybe your team is not successful because they can’t recall a time that they’ve ever been successful.

“I’ve never been on a successful implementation” a co-worker admitted recently. Sure, I’ve been on failures as well, but I’ve also been on successful projects, and I know what it feels like to win. So when I go into any situation, my baseline expectation is success.

Biased Towards Success

Biased Towards Success

But what if it wasn’t? What if I could never recall what it felt like to get to the finish line with well understood requirements, mechanisms for change that were effective, testing that was thorough, and mostly bug-free releases to production? What if my experience was constant production errors, angry users, half-concocted requirements, and non-existent testing?

More importantly, what if the majority of your team’s baseline recall of any software development process….was failure?

In the analysis of project failure business, we focus alot on leadership and methodology failures. And the PMBOK doesn’t really deal with the psyche of the human being except to expand on ways to encourage people to do stuff (ie motivate them).

It’s almost ironic, however, that psychological factors in team formation aren’t discussed in greater depth, because after all, Project Management is about the management of people, through processes, to deliver a certain something in a defined period of time.

Whatcha Thinkin Lincoln? Availability Heuristic and Retrievability Bias

Economics has sought a link between the human psyche and economic decision making through the field of Behavior Economics pioneered by Daniel Kahneman and Professor Amos Tversky a few decades ago. They suggested that human beings process information through pathways of thought that are developed through experience. These pathways becomes rules of thumb against which new inputs are judged. The full list of these patterns, include both the rules of thumb, Heuristics, and many Cognitive Bias’, which are a pre-disposition to inject non-factual errors into our thinking.

I’m no psychologist so I won’t attempt to describe cognitive bias but I’m throughly fascinated by the Availability Heuristic because I think I’ve seen it happen in real life by skewing teams towards either a set of habits that lead to success or a set of habits that lead to failure.

The Availability Heuristic is described in Major Blair S. Williams’ Military Review article Heuristics and Biases in Military Decision Making thusly:

“When faced with new circumstances, people naturally compare them to similar situations residing in their memory. These situations often “come to one’s mind” automatically. These past occurrences are available for use, and generally, they are adequate for us to make sense of new situations encountered in routine life.”

So basically, the Availability Heuristic says that we see our current circumstances through the lens of our available experience, through what we already know.

This leads to Retrievability Bias, where “…the frequency of similar events in the past reinforces preconceived notions of comparable situations occurring in the future.” Major Blair S. Williams.

Retrievability Bias leads us to believe that if something has failed or been successful in the past, it will fail or be successful in the future.

Generally, cognitive bias’ are considered to be common errors in judgement because they are rarely based on objective fact. Nonetheless, imagine if you will, a team full of people who have never been through a successful software implementation. They have nothing available in their experience from which to draw, from which to connect a successful outcome to your current project. Further, due to Retrievability Bias, they may be inclined to believe that successful software implementations are not even possible.

Of course, this phenomena is not limited to software. My daughter works in retail and this summer she worked at the flagship store in Geoergtown, a very posh, upscale part of DC. When school started, she transferred to a suburban store and almost immediately bought home stories of woe.

DId ja hear about that huge massive production outage in Accounting??  Happens EVERY time...

DId ja hear about that huge massive production outage in Accounting?? Happens EVERY time...

The suburban store was disorganized, it was like nobody knew what to do, and nobody wanted to do the right thing. Sales were down, the store felt dead. She said she was confused…she didn’t really understand at all how to even function in that environment. She only knew how to be successful, and how to function in a well run store. Gradually, more transfers from Georgetown started working at the suburban store. The Georgetown store is vibrant, full of life, and highly profitable. And as the mix of employees incorporated more former Georgetown-ites, the whole vibe of the store changed, and sales increased. My daughter and her Georgetown colleagues had no available experience of poor store management and they could only retrieve a successful store experience, not a failing store. (I know..give them time, they’re still only in their teens 🙂 ).

Availability Heuristic and Retrievability Bias could also explain why some sports teams continue to win over and over again. The Chicago Bulls in the the 1990’s for example, with repeat title championships. Those guys had championship available to them and a bias’ towards winning. And some teams seem to know how to lose. My beloved Redskins haven’t been the same since the old owner, Jack Kent Cooke, who had been through many superbowls, died. I believe the new owner has no ability to retrieve post playoff success – he hasn’t felt it, he doesn’t know it.

Changing Thoughts: Two Suggestions

Getting back to Project Management, I think its important to know what people have been through so you can start to build in a new set of available experiences from which to draw. In fact, you may want to think about potentially reversing any negative Retrievability Bias through some very targeted steps.

Visualize Success

Interestingly, research into the Availability Heuristic seems to point to a ‘if you can imagine it, it will occur’ scenario. Note these findings from a 1978 study on the Availability Heuristic:

“..people asked to imagine an outcome tend to immediately view it as more likely than people that were not asked to imagine the specific outcome. In one experiment that occurred before the 1976 US Presidential election, participants were asked simply to imagine Gerald Ford winning the upcoming election. Those who were asked to do this subsequently viewed Ford as being significantly more likely to win the upcoming election. A similar result was obtained from participants that had been asked to imagine Jimmy Carter winning.[4]” Wikipedia

I find it interesting that the US Army Operations Manual also emphasizes the importance of visualizing (see my post on commanders’ visualization) the end state as an important step to success.

This doesn’t have to be a hooky, kumbaya thing. It can be simply, “What do you think would make this project really successful?”, posed collectively to the whole team or individually. The point is to have them start to imagine what success might look like. The research suggests that even just imaging an outcome makes it available to the imaginer; placing it within the realm of possibilities. If it’s avalible to them, they may make slight adjustments in habits, and communications that they would not have otherwise. Instead of ‘why bother’, the attitude could become ‘let’s try.’

Short Early Quick Wins
If you have a team of people who correlate all future projects with many failed past projects, one way to change that is to have them experience a short, early, quick win on the project.

This has worked for me before. One team I started leading mid-stream had many broken processes. My first step was to fix the one that was causing the most pain by eliciting a solution from the team, and putting it into practice right away.   Note that it was more important for me to get any process going so the team could start learning how to work together, than for that process to be perfect.   In fact, the process had flaws, BUT the team learned that they could work together to come up with a solution (key!)  and that they could also experience a win within the software development lifecycle. This basic learning firmly presented an obstacle to any Retrievability bias towards failure. I’m not saying things changed overnight, or that everyone shifted, some people didn’t. But enough of the team did shift such that we used the experience to build more and more successful outcomes.

Final Thought
While disciplined process, defined scope, and visionary leadership are major project success factors, we may need to add the ability to retrieve an experience of success to the list.