Wednesday, September 25, 2013

Faster, Cheaper, Better by Michael Hammer and Lisa Hershman

Faster, Cheaper, Better
The 9 Levers for Transforming How Work Gets Done
by Michael Hammer & Lisa W. Hershman
A Review

A REENGINEERING HOW-TO FOR EXECUTIVES

One of the co-founders of the reengineering movement, Michael Hammer has always focused on how companies get things done more than what they need to do. In Faster, Cheaper, Better: The 9 Levers for Transforming How Work Gets Done, he and co-author Lisa Hershman, CEO of Hammer and Company, offer a detailed framework for improving the key processes in a company — the five to ten end-to-end processes, from product development to order fulfillment, that bring all the value to the company's customer. "End-to-end" are the key words in the authors' approach.

Processes in most companies are fragmented: different people or departments doing different tasks along the process with no real thought given to the efficiency of the entire process. "Most people want to do a good job," write Hammer and Hershman. "They are given goals and they strive to meet them. They focus intently on doing their job correctly and well, and they are rewarded for their efforts. But few understand how their narrowly defined jobs fit into the overall picture of what the company is trying to accomplish."

Value for the customer is not created by a job, it is created by a series of jobs that together form the end-to-end process, the authors argue. This focus on end-to-end processes may remind readers of Hammer's classic reengineering approach in Reengineering the Corporation and with good reason. That book, the authors write, explained why the end-to-end process was the better way to organize the operations of a company. Faster, Cheaper, Better explains how to "harness" the concept to make the company more profitable.

Using the Nine Levers There are, according to the authors, nine levers that companies can use to improve the performance of their end-to-end processes. The first five involve the design and execution of the processes. The authors call these levers "process enablers."

The five process enablers identified by the authors are:

The process design.
Companies need to design new end-to-end processes focused on the needs of their customers and eliminate redundancy in the processes.

Metrics.
Instead of letting each function select its own measures, use customer-focused process measures.

Process owners.
Designate formal process owners — with the responsibility and the authority to improve the entire process — to work with the traditional functional leaders.

Performers.
Redesigning processes changes the way people work. Performers must see their job as part of the whole value-creating process.

Infrastructure.
A new approach to work by the performers requires a new infrastructure to support them — including new compensation plans, new training and development opportunities, a new reporting structure and the necessary tools.

Through their experience with numerous companies, the authors found that implementing these five process enablers could only succeed if four enterprise capabilities were in place:

Leadership.
The leadership of the company needs to think in process terms, not functional terms, and to align their efforts to improve end-to-end processes.

Culture.
The best companies will have a process-based culture that is relentlessly focused on the customer.

Expertise.
Process management and redesign need to be core competencies within the organization.

Governance.
A formal governing infrastructure needs to be in place to implement end-to-end processes, such as a program management office that includes a chief process officer or a process council at the top of the organization.

Faster, Cheaper, Better combines a detailed, extensively researched, yet practical methodology with continuous examples of the methodology's application to the real world — both within the discussion of the methodology and in the second part of the book that offers in-depth case studies. A summary chart at the end of the book, that shows the nine levers in four different stages of maturation, provides yet another guide for companies to improve their processes. This is a business book that delivers on its promise to transform how works gets done in your company.

Monday, September 16, 2013

Why Agile isn't working

Why Agile Isn't Working: Bringing Common Sense to Agile Principles

Agile promises many things, but the reality in the field is often very far from the expectations. Is it agile we need--or an agile way of thinking?

By Lajos Moczar
June 4, 2013
 
Changing Agile Thinking With 3 Common Sense Principles
One thing that's seductive about agile is the name. We like the idea of being agile in our thinking. Agile as a methodology cannot deliver agile thinking, however, and inevitably ends up preventing it.

Think of "agile" as the ability to take the input of all the variable elements of the project—budget, time, design patterns, reusability, customer needs, corporate needs, precedents, standards, technology innovations and limitations—and come up with a pragmatic approach that solves the problem at hand in such a way that the product is delivered properly.

This sounds like a tall order, but really comes down to three common sense principles. If there's one key quality a good project manager needs, it's prioritization: The ability to take the pressures of all project elements and determine which path to follow based on what's most important to achieve.

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It's the role of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

One of the hardest things for many developers is pragmatism. Rather than think practically, they inevitable fall into abstract approaches to problems. I was on one very expensive project based on a purist design in which everything was reusable and could be dynamically coupled together. It was a marvel of abstraction. The only problem was that it didn't work. It had the worst performance I have ever seen in a Java system and was incapable of supporting the required load. The core problem there was that the team attempted to solve real-world problems with an abstract approach.

No matter how virtual technology gets, it's still ultimately based on the physical world that we humans operate in. Physical problems cannot be solved abstractly. Look at any factory machine and see how many oddly shaped parts it contains, each good for just one very vital physical function. Software is no different. Sometimes things are meant for one use only. That's not a bad thing if it gets the job done and functions properly for many years.

Finally, dynamism means the ability to switch strategies when the current one isn't working. Many times, despite our best planning, what seems like a good project, design or development strategy hits a brick wall. The most important thing in this situation is to know when to call it off. If the brick wall is only a brick wall, a bit of brute force—i.e. one or two late nights—will get through it. But if it's really a mountain of rock, it's best not to risk the entire project but, instead, find another way around.
It sounds like a simple concept, but I've watched projects go on for weeks, team members beating their collective heads against the mountain, only to conclude too late that another approach was needed.

Agile promises solutions it cannot deliver. It promotes sloppy requirements, hides the true cost of development and prevents effective management. Contrary to what we're told to expect, this leads to long-running projects, dissatisfied customers and an overall IT ineffectiveness. What we hope to find in the methodology, however, is achievable through agile thinking. With this thinking, we can in fact solve the problems of IT project management and learn how to deliver stable products on time and to budget. If the project team knows how to think and work effectively, then we don't need to look to a methodology to save us from project failures. We can do it ourselves.

Retrieved from
http://www.cio.com/article/734338/Why_Agile_Isn_t_Working_Bringing_Common_Sense_to_Agile_Principles

Lajos Moczar is a senior technology strategist and consultant, operating as The Consultant CTO. When not consulting, he writes on various IT topics. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.