Tools are great.  I absolutely love automated project management tools in particular.  But implementing a tool or changing an organization is often the real effort.  Here are three phases to change we’ve experienced and how they helped us to succeed.

When I take over  a new organization or project or start a new initiative, I usually find it proceeds along these lines:

First, Get Your Own Act Together

1. Get my own team’s act together first.  This means focusing on what our team is doing and how they are doing it.  I’ve seen a lot of leaders, especially military leaders, whose first actions are to “take command.”  This often looked like a salvo of orders causing everyone to jump and run.  The problem I often saw with this kind of approach was that the good stuff that was going on got crushed or run over by all the new commands and initiatives.  The new guy just lost some of the best things that were going on, just because he wanted to “take charge.”

For more on avoiding this see:  Don’t Squash Your Pockets of Excellence

A good commercial example was by a new senior VP at a Fortune 50 company.  This SVP was pushing hard to get changes going in her new organization.  One courageous fellow mentioned that we had just delivered a huge project practically on-time, only a week late — where we were normally 3-4 months late, and that was a great step in the right direction.  The SVP barked out “it was still late!”  End of subject.  The SVP didn’t want to hear about what was already going on, only about what she was trying to do. The organization did not thrive under her and she didn’t last very long.

Instead, one of the first things I try to do as I learn my new organization or project is to find those things that are going well.  These I try to talk up.  Try to say we need to do more things like these.  This helps build support and folks feel confident if something is going well that they will get recognized.

At the same time, I try to find those things that need to be fixed.  This is easy.  Just ask your folks.  I look for patterns in what people complain about or make suggestions for improvement on.  I’ve also seen military officers hear one thing and then immediately send out an edict to fix it.  This again didn’t seem to work well.  I find I like to work problems that many people are identifying, at first.  However, often the key changes and initiatives will come from small groups who have identified something no one else yet appreciates.  These skunk-work activities are the source of some of the best improvements I’ve ever experienced.

See more on asking your staff’s opinion in The Most Underused Tool

While improving my own organization, I usually get “yea, way to go, it is about time they got straightened out” from my management peers and bosses.  However, soon after the initial improvements take hold I generally start to notice some other major issues in improving my own organization.

For example, we finally got a software release out of development and into integration and test.  Within an hour the integration manager dropped a foot deep stack of output on my desk and testily stated: “your guys should at least try and compile the code before giving it to us.”  He then stalked out the door.  I called my managers into my office to look at the stack of error messages.  After a few minutes, it was clear the integration manager’s team had not followed the instructions given to them.  One would think that a foot high list of error messages would suggest that you might have done something wrong.  After further investigation, however, I discovered that in fact, it was normal, in the past, for development to deliver code that didn’t do well when built under the integration team’s process.   I asked my managers to go and, diplomatically and politely, show the integration manager how to get things fixed.

Second, Inevitably We Must Help Others Get Their Act Together

2. What I’ve seen is that as we fix our own organization,  we quickly discover that inputs to and outputs from other organizations impact ours greatly.  So now that we started to get our stuff “right” we now had to help our sibling organizations to also handle it correctly for us to continue to make real progress.

This was the case for the build and integration team as I mentioned above. We had to work with them, fix their process, to realize improvements in our own.  It was also the case that we needed to be willing to change what we gave other teams so as to optimize their process when using our outputs.

In one case, we were coming up on the end of the fiscal year.  We needed to commit the rest of our budget or lose the money.  We had to let several contracts, quickly.  I told my folks to figure out what the contracting officer needed and give that to him.  Don’t give the contracting officer the information and have him figure out what to do with it. Instead, give it to him exactly as he needed it: On the government forms and in the format he needed to use.  My folks were not really happy with this, but they did it.  A few days later, with still a few days before the deadline, my team let me know they had turned over everything to contracting.

I decided to hike over to the contracting office to let the contracting officer know that we were done and ask if there anything else we can do to help them out.  I found the contracting officer in a large conference room with stacks of contracts in piles all over a very large conference table.  He looked up at me and did not look very happy.  It was clear that many organizations had also dumped on him these contracts at the last minute.  I was feeling less good about what we had accomplished at this point.

He looked at me.  Grunted.  Got up and walked over to a particularly large stack of contracts.  He picked them up, said: “these are your contracts” and dropped them, with a smack, back on the table.  He waved his hand over the rest of the table and said: “just about all of these came in before your stack did.”  I inwardly groaned.  “However, I can only execute your contracts because they are ready to go. The rest of these are not.”  He then turned his back on me and I got the heck out of there.  All our contracts were executed by the deadline. They made it because we figured out and then gave him exactly what his organization needed.

One other example.  We were working to get a software organization up to SEI CMM level 2 (a software management standard).  Everything was going pretty well except for the software quality department.   They had been saying for years that our software activities were bad.  They should know as they were the “quality” department!  Their manager called themselves the “black hats.”  They would walk into a software development activity and tell them everything they were doing wrong.  Well, the SEI CMM standard had the quality organization doing specific activities against specific standards and in support of specific goals.  Our quality organization was not interested in those standards or activities.  They liked to just walk in and tell folks what they personally thought should be done differently.

So, after about nine months of working towards the CMM standard, the organization decided we must be there by now, and so asked to be formally assessed. The results?  Everyone was good, except for the quality organization.  We failed the assessment. It took another nine months to confidently make the needed changes and get reassessed.

So I’ve discovered that to continue to improve my own organization, I had to improve how we handled the inputs and outputs to other organizations.  In many cases, we had to help our sibling organizations do a better job with what we gave them.

Often when focusing on sibling organizations, I would start to get feedback such as “hey, stop that, you are the guys that needed to improve, we are doing things right!”  However, the bosses would also often comment “yeah, we knew they needed to improve too. Keep it up, you are doing great.”

Third, We May Have To Help The Bosses Get Their Acts Together

3. Once our own organization is doing well and our sibling organizations are now getting in sync, the next step is often the toughest one.  This is where we now notice that the current inhibiting problems are because of actions, edicts, and policies from … our bosses.

I’ve discovered two typical reactions from bosses once I approach them with recommendations on things they needed to do differently.  About half will say “OK, are you sure you want me to do this instead?  I can do it, but I need you to be certain that this is what is needed.”

The other half will say “Oh, no — I don’t need to change.  I’ve supported you up to this point, but now you’ve gone too far!” These bosses seem to think that if they make a change, then they’ve admitted to being part of the problem. While all this time they’ve been saying the problem was “over there.”  No way they were going to change.

This is often the toughest part of a change and where often improvements slow way down.

Summing it Up: Making the Change

So trying to improve the organization around us looks like:

1. Get our own group’s act together first
2. Help our sibling organizations, who we exchange internal products with, make any needed improvements
3. Help the bosses see what changes they can make to further the improvements.

This may be a bit different to more formal “change management” techniques, but it works — and has worked for me for many years.

For more insights, see Why Change Management Is Hard And How To Succeed Anyway.

How have you been successful at making changes in your organization and project?