Projects: A business within a Business?

Projects are an investment. Their purpose may be to implement application software or implement process improvements or to reorganize one or more functions, etc. But in the end, the expectation is that the organization will be better off for having made the investment. That’s precisely the point of any business investment.

If you wanted to evaluate how well a business was doing, you’d probably want to see their Profit and Loss Statements (P&L) as well as their Balance Sheet. Any business that didn’t operate with these, is not going to be taken seriously. I don’t think we’d accept someone telling us, “Oh, we’re doing fine.” We’d insist on the financials. They would tell us how well the business was doing.

Why not do the same thing for our projects world? Why not create a Projects Enterprise that can be managed like a real enterprise?

What financial statements do is much more than give us a method of accounting. They make people accountable over multiple transactions. You may have accountability at the single project level, but do you have it across all projects and across time? Can you demonstrably show that your project management enterprise is, in fact, delivering greater and greater value?

I’d like to propose two Project Enterprise Statements:

  1. The Current, Predicted, and Realized Statement (CPR)
  2. The Balance Sheet

Every project should change the value charge for some stakeholder account. For example, a project may intend to change profit or revenue, both shareholder accounts. Or it may change safety, or employee compensation, or stress, all employee accounts. Each value that is expected to be changed can be seen as an account, just like in business. Every CPR Statement would contain a list of accounts that need to be changed and a list that should remain stable. For each account to be changed, we would provide the following:

  1. Current: The current value, however measured or evaluated.
  2. Projected: The value we are aiming to achieve.
  3. Realized: The value actually captured or achieved.

A CPR would cover before, during, and after the project. It would be a tool for implementing total project memory. No project should start without it. No project is truly complete until we know what has been achieved.

Next week we’ll explore the Balance Sheet.

End of Part I

Check out the new Schulich 3-day program, “Designing and Deploying Business Processes.”

Angelo Baratta

Posted in Uncategorized | Leave a comment

Theory vs. Practice

I attended the PMI SOC Professional Event this past Saturday, and it was an excellent event.

One presenter began his session with words to this effect: “This presentation contains no theory, only practical advice.” People applauded. It was a popular session. Everyone wants practical advice they can use tomorrrow morning. Maybe that’s why tomorrow is likely to be just like today and yesterday. It seems that there are many PM and BA professionals who hate theory, who believe that theory is a waste.

That needs to change. Call me crazy, but I think that many of our problems are due to lack of coherent theory rather than lack of practical advice. There’s an old expression that says, “You can’t get there from here.” The automobile, the airplane, the mobile phone, television, radio, the computer, vaccinations, miracle drugs, space travel, modern highways, cruise ships—and I could go on—are only possible because of theory. None of these things could have come to be without theory. None of these things came to be based on practice.

No amount of practical advice could convert a horse and cart to an automobile. No amount of practical medicine could have come up with the polio vaccine. All these things have one thing in common. They were developed based on principles that resulted from proposing and proving some theory.

Practice is the first stage of any profession. Theory is the next stage. True progress happens when we leave the first stage, based on authority, and move to the second stage, based on experiment and proof. Practice has always been dominated by a few individuals in authority telling us what is correct. Theory allows everyone to participate in the discovery of knowledge. All they have to do is propose a theory, an explanation of WHY things happen, and provide a way to prove the theory in such a way that it is repeatable. Many people working on a problem is better than a few people holding on to their “way.”

Every child is born with the built-in instinct to develop theories. A child does not ask the practical question “how.” Instead, she asks the theory question “why.” When you know “how” you can only execute under fixed conditions. When you know “why” you can adapt to any condition. A builder knows “how.” An architect knows “why.” Our focus has been on developing builders and PMI and IIBA have helped in that regard. But we have enough builders.

Now we need more architects, people who can help us understand the whys so we can develop better hows.

So next time someone says, “That’s just theory. It’s not practical,” remember that the most practical things we have today are all based on theory. Things based on theory evolve and improve at a rapid pace. Things based on practice barely evolve at all. The horse and cart were around for centuries with little change.

Embrace practice based on theory. It is the way forward.

I hope you join me at one of several upcoming sessions that explore theory and practice. If you’re interested in becoming a Business Process Architect I invite you to consider the upcoming course at Schulich.

I welcome your feedback.

Angelo Baratta

Educate Learn Master

P: (905) 270-7591

Posted in Best Practice, Change, Improvement, Performance, Process Design, Uncategorized | Leave a comment

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”.

Posted in Change, Improvement, Performance, Process Design, Teamwork | Leave a comment

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”.

Posted in Uncategorized | Leave a comment

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

Posted in Uncategorized | Leave a comment

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:

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

Engineer your Performance. Execute the Blueprint.

Posted in Best Practice, Change, Improvement, Performance, Process Design, Teamwork | Tagged , , , | Leave a comment

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:


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

Engineer your Performance. Execute the Blueprint.

Posted in Best Practice, Process Design, Teamwork, Uncategorized | Tagged , , | Leave a comment