Management Myth 28: I Can Standardize How Other People Work


Johanna Rothman writes that organization-wide standards don’t help if management imposes them. If people ask for help with standards, then you can provide local help to each team. And if the teams are part of a program where you have one business objective common to multiple projects, make sure the program understands the problem.

“OK, I’m really glad we can start this management meeting now. It’s time to talk about standardization. I want to create standards for our projects. I want to standardize on agile for all of our projects.” Joseph, the CIO, thought all of his directors would be pleased.

“Uh, Joseph, are you telling us you want us to go ‘all in’ on agile right now?” Cathy, the QA director, sounded concerned.

“Sure. Why not?”

“Well, we haven’t finished our pilot project, for one reason, and we don’t have enough money budgeted for training,” Dave, the development director, said. “And while I think agile is a great way to go for many projects, our business counterparts have to think so, too. We need to bring them with us. Right now, they’re still thinking in six-month chunks. You can’t standardize on agile without changing how they think.

“Why do you care how we deliver, anyway, as long as we deliver effectively? Our job is to solve problems. Your job is to make sure we are solving the right problems. If you decide which problems we solve by managing the project portfolio, we will decide how to solve the problems.

“What if we decide that we need to prototype some architecture for a while to reduce technical risk? Are you going to have my head?”

Joseph looked at Dave for a minute, then said, “No, I’m not. But I thought you liked agile.”

“I do. But the developers and I don’t quite understand refactoring to patterns at the architecture scale. We’re working at it. That’s the same way that Cathy and her team don’t always understand how to create tests and refactor to test automation all in one iteration, right?”

Cathy nodded.

“Transitioning to agile—or any one other approach—isn’t a slam dunk just because you declare it,” Dave continued. “It’s a change.

“And why should we use just one approach? Why shouldn’t we iterate on architectures or designs for a while if we want? What’s wrong with that? And what about trying kanban instead of iterations? Why can’t we do that? Why do we have to standardize on anything? Why can’t we experiment and see the results of our experiments?

“I feel as if we are finally getting out of the yoke of waterfall. I don’t want to be back in the yoke of something I don’t understand. You hired me because I can think. I hired people because they can think. So did everyone else in this room. It’s time we let them think about how they do their work, not just what they do.

“I say forget standardization. Our projects are different from each other. Why should we use the same approach on each project?

“Let’s tell people the results we want and use timeboxes to make sure we get the results in a reasonable amount of time. Why do we have to do more than that?”

Joseph leaned back in his chair. “OK, as long as you reflect on your experiments and fix them when they go wrong, you have a deal.”

Standards Provide Senior Managers a False Sense of Security
When you have a “standard” approach to projects or anything else in your organization, your managers feel as if they have a sense of security. It’s a false sense, but it is there.

They use that idea of a standard as an assumption that the work will proceed smoothly. How often does that happen? Not often enough!

You can standardize work on an assembly line and make the work safer and more efficient. But knowledge work? When you standardize knowledge work, you run the risk of making the work boring, less efficient, and not oriented to the real goal of your project.

Knowledge work is unique and encapsulates its own learning. It’s why each project should design its own approach, whether it starts off as waterfall, iterative, incremental, agile, or some combination. There is no one right way to do all projects. Each project team has to decide how and what to do for its own project.

Imposing a Standard on Someone Else’s Work Is Wrong
Except for safety or regulatory reasons, there is no reason to impose a standard on someone else’s work—especially if a manager does so.

When managers impose standards, they implicitly say, “I don’t trust you to do your jobs. Here. I will tell you how.” Would you want to do your job that way? I wouldn’t.

I don’t mind having deadlines. I don’t mind having structure of maximums or minimums, such as word counts for columns or sizes for data structures. I can live with constraints.

But when managers told me how to do my job, I didn’t live with that very well. I always thought of ways I could do it better. Always. And some of my managers didn’t appreciate those thoughts.

Standards Try to Prevent People from Thinking
Worse, many standards try to cover all of the potential problems in a process. The standard wants to prevent people from thinking. That’s how we got to big, honking binders of process.

Why do we hire people? To think and solve problems. Do we ever not want people to think? No. We want people to think. We want people to think hard. We want people to solve problems, whether it is with the process or the product.

We hired these people because we thought they were smart. They are. Let them show us how they apply their problem-solving skills to the project itself, not just the problem domain.

What If People Need Help?
If the people ask for help with standards, then you can provide local help to each team. And if the teams are part of a program where you have one business objective common to multiple projects, make sure the program understands the problem. Let the delegates to the program team solve the problem at the program level. If they need help, they will ask for it.

In my experience, organization-wide standards don’t help if management imposes them. After a while, the “way we do things here” becomes part of the culture, and you don’t need standards. People see useful things and they copy them from project to project.

But standards and standardizing, especially from management? Let the people solve problems. They are good at it. And if they aren’t, let them practice.

Read more of Johanna's management myth columns here:

User Comments

Madhava Verma Dantuluri's picture

All meaningful questions and the concerns being faced in the industry. Well driven article.

April 3, 2014 - 12:07am
Jim Miller's picture



Sorry but I strongly disagree, standards are extremely valuable to an organization.  There are hundreds of studies that support the need for standards.  The best and most popular is the practices and principals of Six Sigma.  As everyone knows Jack Walsh used documented well-structured standards to turn GE around.  There are thousands of examples to prove that standards are need.  Remember, SOX was pasted because there were no official accounting or financial standards!


The answer is not to do away with standards, remember this was attempted in the 80’s and it did not work then, but to create and maintain standards that add value.  When an organization implements a VALUE ADD PMO (the P stands for Portfolio, Program and Project Management) they can increase throughput upwards to 30%.  This can only be done by using documented standards.


Here is the real question, what is used to measure management performance?  It should be measurements against standards.  But in most organizations IT departments they do not utilize measurements or standards correctly.

April 3, 2014 - 12:51pm
Johanna Rothman's picture

Hi Jim,


It depends on what the standards are. If you try to shoehorn everyone into one kind of approach to project management, I don't see how you succeed--unless you have all the same projects. If you use GE as an example, they failed at that for their software organizations. Yes, they succeeded for manufacturing. Software development is not the same as manufacturing.

Software projects are about learning. Our projects include innovation. If you have a project without innovation, of course, standardize it. Maybe it doesn't even need to be done by software people.

But, if you want innovation, I don't see how you get to standardization. And, in this example, which is what I see much of in my work with organizations, I don't see why any group of managers would impose their solution to a problem on the people doing the work.

The people doing the work should develop the solution to the problem.

I like your question a lot: What is used to measure management performance? I don't agree with your answer (I bet you are not surprised!). The world is too volatile to measure against standards. I'm all about measuring against outcomes.

April 3, 2014 - 2:07pm
Joe Astolfi's picture

+1!  Thank you Johanna.  You are spot on again.  Standardization gives management an illusion of control and makes them feel better.  Unfortunately, it is just that - an illusion.  Let's focus less on following rules and processes and more on innovating to achieve the desired outcomes.  

April 4, 2014 - 7:54am
Johanna Rothman's picture

Joe, thanks so much. Defining outcomes is difficult. It is necessary, but difficult.

It is different than management by objectives, also. No wonder our managers want to manage with standards!

April 4, 2014 - 10:29am

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.