The Value Deficit

When a project fails to deliver promised value, it creates a deficit. An investment was made, but no value was delivered. Who pays for this deficit? We all do.

• Shareholders pay because they get no return.
• Project members pay because they get no credit for their hard work.
• Management pays as they get the blame.
• Employees pay because of the additional risk and pressure to “work harder.”

Sometimes the price can be very high indeed as the organization outsources part of its work elsewhere. In the worst case, the organization moves all its work somewhere else. This vicious cycle can be reversed. But only if the true root cause is addressed.

• Project management has not addressed this.
• Process improvement has not addressed this.
• Developing people has not addressed this.

In a recent presentation, the dean of a leading MBA university program stated that the challenge is not so much to produce graduates who are good at problem solving but rather to produce graduates who are good at knowing which problems to solve. Both project management and process improvement suffer from the same root cause issue. They are good at delivering symptomatic relief (problem solving). They are poor at identifying problems worth solving (root problems). How do you know when you’re solving symptoms instead of root problems? It’s actually quite easy. If the problem keeps recurring, then it’s a symptom.

Are you encountering the same issues on every project? Even a casual survey of articles, books, and presentations will tell you that we are discussing the same problems today that we were solving five, ten, and even twenty years ago. We are still addressing the symptoms.

• Lack of management support
• Poor requirements
• Busted budgets
• Late delivery
• Frustrated users
• Minimal engagement
• Lack of accountability.

These are all symptoms. They are not the root problem. They are the consequence of poorly designed processes, projects, and accountability structures, among other things. Most methodologies are actually pretty good, but if we keep applying them to the symptoms, the problems will never go away. How do we stop this endless cycle? We have to find the root causes. And the root cause may be different for each organization. That means you can’t pick up a book or attend a presentation to find out what the root cause is for your process, for your project, for your organization. You have to figure it out.

More Perfect by Design introduces the Relational Process Model. It is a framework that will help you to find your root cause, not the root cause. It is methodology-independent so you don’t lose your investment in people or technology. Instead, the Relational Process Model will help you leverage your investment to deliver more value and reverse the trend. It’s a long-term approach that delivers and sustains results in the short, medium, and long-term. If you want to deliver more value and achieve greater success, let’s have a conversation.

Any comments? I’d love to hear from you.

Learn more about value, how to identify it, how to measure it, and how to increase it in my new book “More Perfect by Design: The science of designing more perfect business processes”.

Failure is like manure …

I attended a business process improvement SIG recently where the topic was “Can Organizations Learn from Failure?” The discussion was interesting and there was a general observation that, in general, organizations have a tough time learning from failure because they would rather forget it ever happened.  After going to sleep that evening I suddenly woke up with a revelation. I took the time to write it down because come morning I knew I’d forget it. So here it is.

Failure is like manure. When it’s fresh it stinks and it burns whatever it touches.  But if you pick it up quickly, add some hay, and let it rest for a while, you end up with a compost of rich nutrients that will help plants grow.

Failure is the same. As soon as it happens, the failure needs to be corrected or  dealt with quickly. But then it needs to be set aside to compost, perhaps with a few previous failures. Once it’s composted we can return to it and use it to fuel positive growth and improvement.

Of course, depending on the nature of the manure, the environment, and the size of the pile, it may take more or less time before it can become useful.

Any comments? I’d love to hear from you.

If you have a moment or two consider checking out my new book “More Perfect by Design: The science of designing more perfect business processes”.

What is Design?

There is a lot of chatter about design being an emerging business process discipline. But what exactly do we mean by design and aren’t we doing it already?

Well of course everyone is engaging in some level of design. For example, if we want to open a bakery, then we have to know how to make bread. We have to have a design for making bread. That’s what we would refer to as functional design. Every process must have some level of functional design (FD). Of course the FD depends on the product we are making. Making a car requires a different FD. Processing a car loan requires a yet different FD. But the ability to functionally make a car, or a loaf of bread, does not mean that we can run a bakery or an automobile business. To do that we have to compete against others. And that means that other performance factors become equally important.

So a process can have many performance characteristics.  One would be product quality which relates directly to functional design. Other characteristics could include: speed, flexibility, changeability, throughput, capacity, start-to-finish time, work-in-progress levels, transparency, human friction, and many others.

Each of these would need to be designed. But each characteristic may be driven by one or more  factors. Sometimes different characteristics are a function of the same factors but in conflicting ways. Design is about optimizing around the important characteristics, taking into consideration all the factor conflicts in order to achieve some stated purpose.

So we can define design as follows: Design is the art, practice, and science of discovering constraints and choosing among options in order to achieve ever more perfect performance.

Some key questions for evaluating a design framework might be:

• Can we compare two different designs?
• Can we determine the best case for a given performance characteristic?
• Can we determine the factors or drivers for a given performance characteristic?
• Can we determine which characteristics have conflicting factors?
• Does it include technical, method, and human factors?
• Does it consider both hard and soft factors?
• Can we determine if we are making progress with respect to performance?

Have any thoughts about the future of business process design? Let us know.

To learn more or purchase www.MorePerfectByDesign.com

Design: The Ultimate Human Discipline

What is design and why is it important to an organization? Design is the art, practice, and science of developing a blueprint for getting us from intent to an implementable solution that when executed will achieve the intent. Design is the art, practice, and science of choosing. And that means that everyone in an organization is participates in design at some point or another.

Design is important because there are many more choices which lead away from the intent than there are leading to the intent. Good design is difficult to accomplish without knowing how each decision affects the ultimate intent. An organization that masters design is more likely to achieve its intent than one that carries out design through informal, adhoc methods.

Design integrates people, functions, and technology to achieve greater value for all. It brings people together. Of course, we mean good design. Bad design does the opposite. And organizations are plagued by poor designs that are the result of local, short term, situational, and sometimes self serving choices.

Humans are the only entity that truly engages in design, making it a unique human discipline.  Organizations that want to thrive, not just survive, should investigate the opportunities that process design mastery can provide.

Interested in more? Try these articles:

• Why is Business Process Design the Future of Business Analysis – Business Analyst Times
• Tyranny of Best Practices and Its Effect on Requirements Elicitation - Business Analyst Times
• Value Triple Constraint: How to Evaluate Project Value Delivered - ExecutiveBrief

ePPM by Design™ – the most complete process design and requirements framework yet.

Engineer your Performance. Execute the Blueprint.

www.PerformanceInnovation.com

Requirements are stable. So why are they always changing?

I often hear people say “I spend over 50% of my time managing changes to requirements.” Does this apply to you?

Actually I would argue that requirements change very little; they are quite stable. On the other hand, they appear to change frequently and constantly during the entire development cycle, including Requirements Elicitation. This sounds like a contradiction. Let me clarify:

A requirement changes infrequently. But a statement of requirement tends to change frequently and constantly.  A requirement is a process need that must be met in order to achieve some stated organization objective. A statement of requirement is an individual’s perception of a need, which may be a process need or it may be a personal preference (desire). The reason the statement of need changes frequently and continuously on many projects can be traced to a weak Requirements Elicitation (RE) process. Many RE initiatives are based on the assumption that the subject matter experts (SMEs) know the requirements going into the process. They focus on clarifying and capturing the requirements from the SMEs through interviews, workshops, questionnaires, etc. So, the whole time the BA is capturing the requirements, the SMEs are trying to think through what the requirements should be. The end results are poor, incorrect, irrelevant, and ever-changing statements of requirements.

A more realistic assumption is that the SMEs do not know the true process requirements at the start and that their stated requirements contain significant personal preferences. True requirements should be focused on understanding the process needs, setting aside personal preferences. This can only be achieved by a cross-functional team led by a BA. The team should be trained in how to separate process needs from personal preferences.

Current Requirements Elicitation approaches focus more on how to extract information from users, rather than how to discover requirements from processes. Requirements are the output of process design. So, true requirements can never be achieved without a proper process design step.

Interested in more? Try these articles:

• Tyranny of Best Practices and Its Effect on Requirements Elicitation - Business Analyst Times
• Value Triple Constraint: How to Evaluate Project Value Delivered - ExecutiveBrief

 

ePPM by Design™ – the most complete process design and requirements framework yet.

Engineer your Performance. Execute the Blueprint.

Where do True Requirements come from

The IIBA BOK defines a requirement as:  

1.  A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2). 

That may be what a requirement is but where does it come from. A requirement typically comes from a subject matter expert (SME) or stakeholder as part of the Requirements Elicitation process. But that’s not from whom a requirement should come.

What a BA is trying to do is to improve the value delivered by the organization through its processes. So a requirement should be a statement about what a process needs in order to deliver its specified value to the stakeholders. So Requirements should come from the process. But we can’t directly interview the process. So, we interview the people that participate in the process.

True Requirements are produced as an output of a systematic process design effort lead by a Business Analyst that is also a process design master. The Business Analyst or Process Analyst should lead a cross-functional team through process design to produce True Requirements.

True Requirements come from the process through a process design team (BA, SMEs, stakeholders) during a systematic process design effort.

In order to evolve, a BA needs to become a process design master. That’s the future for the Business Analyst. And it’s a brighter future filled with greater opportunities and successes.

Interested in more? Try this article: Tyranny of Best Practices and Its Effecdt on Requirements Elicitation www.batimes.com/articles/the-tyranny-of-best-practice.html

 

ePPM by Design™ – the most complete process design and requirements framework yet.

Engineer your Performance. Execute the Blueprint.

PM Research or Stagsearch – Why PM research is holding back progress

I attended a presentation not long ago about project management.  The speaker presented research findings on why projects and PMOs are failing or at least not succeeding.  The interesting thing was that there was nothing new or different about the research findings.  It seems that projects continue to fail at the same rate and for the same reasons as they did five, ten, fifteen, and even twenty years ago.

It set me thinking about “PM Research”.  There are certainly enough organizations out there doing so called research.  But research is supposed to lead to advances.  So why isn’t it.  The answer that came to me was that there actually isn’t any research.  There is stag-search, stagnant research.

What if we used the PM Research approach to improving cancer treatment? Imagine compiling a questionnaire and asking doctors what they thought the causes were for failure in cancer treatments.  Then we receive responses, collate them and publish them.  Maybe we surveyed 100 doctors, and 1000 doctors read the results.  Next year we do the same thing again.  Pretty soon everyone has seen or heard of the “research” results.  So what people think is based on what they have read from these “authoritative sources”.  Pretty soon all the research produces pretty much the same result.

What is the problem here?  The problem is that we aren’t doing research into the cause.  We are doing research into what people think the cause is.  That’s what is happening in project management.  The research shows pretty much the same thing year after year, because we all think we know the cause.  But there is no progress being made, because there is no actual, verifiable research into cause - only surveys on opinions.

Do yourself and your organization a favor.  Don’t use the research as your basis for moving forward.  Remember that it represents opinions from sources which are currently failing at project delivery. So, they are unreliable.   You are much better off to focus on your own research, in your organization, trying to understand the causes for your project problmes.

But there is also another problem with the “Reseach”.  Take the example of “lack of executive support”.  This one comes up often and usually in the top three.  This cause is like asking someone why the company went bankrupt and receiving the answer “because the shareholders pulled out their money”.  OK, that may be technically correct, but why did they pull out their money? Could it be because they saw the business was failing?  So, even though pulling out money (support) may be the proximate cause of bankruptcy, it doesn’t explain why the company failed, anymore than does “lack of executive support”.  The reasons given in most surveys don’t go deep enough to give us insights into what needs to be changed.  They are the kind of answers one gives when they are in a hurry and don’t have time to actually give the question due dilegence and consideration.  Is it possible that in today’s busy world, responders are answering questions fast, just to get their free copy of the results. 

PM Research is not useful for several reasons.  The first is that it reflects individual and unsubstatiated opinions.  The second is that just as there are many kinds of cancer and many patient conditions, there are many different kinds of projects and organizations.  Even if you knew a particular cause of faiure for a fact, it doesn’t mean that it applies to you. No one from outside can tell you what the best treatment would be for your, sight unseen.

If doctors tried to presribe a course of action to a patient without any diagnosis, but based solely on the top 5 answers from a survey, they would be disbarred for malpractice and incompetence.  In project management, of course, it’s just standard procedure.  It’s time for organizations to take control of their own project mangement practice and leavet the “so called survey research” whre it belongs.

The bottom line is that despite the research, there has been no progress in the bottom line impacts of projects in the last two decades.  Isn’t that enough to make us at least question the standard answers?

Have an alternative view? Please share.

Angelo Baratta

Performance Innovation

www.PerformanceInnovation.com

ePPM by Design™ - Designing projects for success and measurability

Best practices are not always better

Clients often say to me “We use best practices.”  When I go back to those clients a year leater, they are typically using the same best practice.  Best practices take a long time to make it to the front of the line, often decades, sometimes a half century (Lean, Six Sigma, PMBOK, etc.).  Best practices are very alluring because you can shut someone down easily.  If they ask “Why do you do it that way?”,  instead of answering “because we’ve always done it that way”, now you can simply reply “because it’s a best practice”.  One simple statement shuts down the debate. And what with all the pressure to get more work done, who has time to reflect on current practices.

But remember that most best practices were developed by someone else, under different conditions and long ago.  So it can be like taking a vaccine developed 20 years ago for a flue strain that existed then.  Unfortunately that flu is very different today.  Don’t get me wrong, I’m not saying best practices are bad.  What I think is risky is the attitude that a best practice is an end point.

If you don’t have a good practice of your own, then you can begin with a best practice.   However, the goal should always be to validate the practice and to seek a better practice. Whereas best says I’m done, better says I’m on a journey that doesn’t end but where each new destination is more rewarding than the previous.

So, the next time someone asks “Do you use best practices?” perhaps you will answer “No, we have grown past that.  We now use better practices!”

Angelo Baratta

ABaratta@PerformanceInnovation.com

www.PerformanceInnovation.com

Continuous Improvement – What is its true value?

Some people are still trying to convince us that continuous incremental improvement will lead to large gains.  Is this really true?  I know that for many years I was convinced of the truth of this statement.  Then a few years ago, I went on a tour of the Toyota plant in Cambridge Ontario.  I felt a little like I was at Disney.  They put us into one of those little tram jobs that you see at Disney.  Equipped with headsets, we set off to drive through the very large plant.

It was not at all what I expected.  As we drove through the highly organized plant, replete with robots, a question popped into my mind:

             Who designed the factory that builds the cars?

I used to be impressed with the quality of the Toyota cars.  But this was a hundred times more impressive.  Here was a machine (the plant) which was huge in size and complexity beyond any car.  And yet, someone had designed it to pretty flawlessly produce a large variety of automobiles.  I could suddenly see that there was no way in the world that this complex factory could have emerged by starting off with a poorly designed factory and incrementally improving it.  This had to be designed that way from the start.

You can’t produce a Ferrari by continuously improving a Corolla.  You have to start fresh.

Let me put it another way:

How many improvements would you have to make to an automobile to turn it into a jet liner?

Of course, we want to build our knowledge.  But to build a machine that flies you don’t start with one that doesn’t.  And so, I believe that in many ways Michael Hammer was partially right when he said “Don’t automate, obliterate”.  The reason that paradigm failed was that Mr. Hammer didn’t provide us with any way to design processes from scratch.  All we knew was how to improve the one we already had.

So, what then is the true value of Continuous Incremental Improvement?  Every paradigm has a limit.  When a new paradigm or a new process is designed, it is never at its peak at the start.  What CPI does is insure that we inch our way towards the peak.  But even that is not the true value of CPI.  In the process of inching our way towards the peak, what we get as a side benefit, is preventing the process from sliding backwards.  We ensure that we don’t lose the gains we have made.

The truly big benefit of CPI is to maintain and slightly increase performance while waiting for the next paradigm shift.  If you were to look at organizations that don’t have a systematic way to continuously improve you would find that all their processes deteriorate slowly then suddenly, until the performance is so poor that we need to undertake a process improvement effort.

Continuous Improvement does three really big things for an organization:

1. Acts as a backstop to prevent performance deterioration.
2. Keeps people engaged in thinking about how work gets done and this keeps them motivated.
3. Keeps them supple with respect to change.  By introducing many and frequent small changes, people are more ready for the occasional but important big change.

So don’t try to sell CPI as a source significant productivity gains, but rather as a necessary discipline to prevent significant losses due to backsliding while at the same time paying for itself through modest but important gains.

A business process is like a factory.  If you want the factory to produce exceptional products with amazing efficiency, then it’s not enough to know how to functionally produce the product.  You have to know how to design the factory itself (the process).

Organizations today are quite good at designing their products and services.  But they haven’t even scratched the surface on designing the processes that deliver those products and services.  The majority of current processes are based on best, leading or personal practices which are based on past experience, often over 50 years old.  The best practice approach is no longer a best practice.  We must move towards designed performance. Process design needs to become a core competency in every organization.  What actions are you taking to move yourself and your organization in that direction.

Angelo Baratta

(905-270-7591)

www.PerformanceInnovation.com

ABaratta@PerformanceInnovation.com

ePPM Future Blue™ – the art and science of designing near perfect processes.

Moving from Best Practice to Designed Performance

How good is best practice?

Many people believe that if they are following best practices, then they are in the lead. I challenge that view.  Let’s explore how best practices originate.

We start with personal experience.  Based on this, each of us develops a personal practice – the way we do things.  At some point an organization may decide that it wants some level of standardization.  So, it will cull the personal practices down to an organizational practice.

An organizational practice will remain that way forever, unless it somehow gets communicated to the outside world.  So how does this happen?  What will typically happen is that consultants act as carriers from one organization to the next.  They may see something they think is attractive and they may bring it to some other organization.  Or they may write about it.  Of course consultants will typically only pay attention to a practice which holds some potential for business for them.  The practice will begin to be talked about at conferences.  It will show up in magazines and journals.  Eventually books may appear.  What is really happening is that the practice is being promoted rather than proved.

And how long does all this usually take? It takes from 10 – 50 years.  That’s right years, not months or weeks or days.  So we could actually refer to best practices as  very old practices.  The company that originated the practice has probably long since evolved it to something quite different.

Maybe you don’t believe the 10 – 50 year timeframe.  But look at such things as Six Sigma which is just now starting to enjoy some sort of penetration. Six Sigma was developed in 1986.  But its foundation ins statiscal process control goes back to 1920 and even before.

And what about Lean? Most of Lean was developed after World War II with some elements dating back to the late 1800’s.  And it too is just now beginning to gain a foothold.  What about such standards organizations as PMI.  Their standards are based on the personal practices of the those people who participated in writing the standard.  And it takes many years between guides.

Can you afford to wait 10 – 50 years?  By the time the best practice reaches us, is it really a best practice anymore?  The conditions and the situation that existed so many years ago, no longer exist today.  The target for many of the Lean methods such as kaizen was an uneducated factory workforce.  Do your employees fit this profile?  They probably don’t.  So why would you apply a practice not designed for them at all.

It is unfortunate, but a good many so called best practices take many years to reach us, and then many of them quickly fade into the “flavor of the month” category.  Actually, given the time they take to become known, it would make more sense to call them “flavor of the decade”.

Best practices usually have strong proponents behind them who promote them vigoursly pointing out the successes while ignoring the failures.  Best practices tend to be sold on faith and they crowd out new ideas.  In the end the best practice approach significantly slows down progress.  This has been true throughout history.  It was true then, and it’s true now.

In today’s environment we can’t afford to wait for someone else’s best practices.  We need to design our own best practice.  That means that we need design based methodologies that can turn out new processes in months, not decades.  If we look at history, we see that practice based approaches move at the speed of evolution – slowly, veeeery slowly.  And they are often ineffective or counterproductive.

On the other hand, if we look at science based disciplines we can see that progress is significantly faster.  Take medicine, for example.  If we look historically at practice based medicine, we can see that it took hundreds of years to make any kind of progress. But science based medicine has probably produced more advances in a single year, than practice based medicine was able to produce in a century.

If you want to achieve rapid, continuous, and sustainable progress, then you need to move your process design from a practice, to a science based discipline.  If you don’t, then you will be 10 – 50 years behind your competition.

Angelo Baratta

(905-270-7591)

www.PerformanceInnovation.com

ePPM Blue Ocean Process Design™- the art and science of designing near perfect processes.