Wasting Management Time

According to the Harvard Business Review, fully 90% of managers waste their time on ineffective activities. Only 10% of managers use their time both effectively and wisely.

The job of managers is to move the organization forward. The manager is paid to change the direction of the enterprise, not to maintain the status quo. The secret to achieving this is to apply focus and energy.

A large number of managers have neither focus or energy, they are what are termed the procrastinators. These managers are paralyzed by fear of failure, and therefore fail to take action. These managers are a real problem, and require special care, because otherwise, its difficult to get any useful results from them.

Another large group have energy, but no focus. They spend their time jumping from activity to activity, but this group, mistakes action for results. To handle these managers, its important to keep the number of tasks assigned to them small. Overloading these managers with more than a few tasks will lead to lots of apparent activity, but very few results.

Yet another group, has focus, but no energy. These are the disengaged. They are capable of excellent work, but have become discouraged and therefore approach their work in a half hearted fashion. These managers may have started with both energy and focus, but have been discouraged by a stifling organization culture. These managers can be rehabilitated, through a little encouragement and attention.

Purposeful managers, have both energy and focus. They don't get distracted by unimportant issues, they focus on things that count and they commit to moving things forward. These are the people that get things done and are the real source of competitive advantage in companies.

As an individual in the organization, ally yourself with purposeful managers for two reasons. First, these managers get results and being associated with them will cast a positive halo on you. The second reason, is that associating with purposeful managers helps you in turn to become purposeful, which will usually result in both attention and promotions.

Business Models and the Scientific Method

In many respects, creating a business model is like creating a scientific theory and performing experiments to prove or disprove the theory. If our theories are correct, the experiment will turn out as we expect, and the business will prosper. If not, then the theory has to be adjusted to reflect the results of the experiments. The scientific approach can therefore yield real benefits and results when creating a business, as opposed to a trial and error approach based on luck.

For example, let's say that we think customers will be willing to pay a lot more for 'green' hybrid cars. This is the bet that Toyota is making with the Prius. To verify that we are right, we would need to figure out what channels to use, who to sell to, how to market the vehicle, how to price it, etc. There are a lot of things that we could do, and only through disciplined experimentation, can we really be sure what will work.

In many ways we see an explosion of experimentation in business models today. It's not just Web 2.0 companies, but companies such as Walmart, Southwest Airlines, Netflix, Costco and many others which have experimented with their business models and come up with winning formulas. This trend is likely to continue, since globalization is creating both more opportunities and more players. The real work of innovation is to find, create and adopt winning business models and adjust them continuously so that they continue to deliver results.

Adjusting the Business Model

One of the things that successful companies understand is that a business model is seldom perfect when it is first formulated. It may work in one country, but not in another. It may work with one set of customers, but not with another. Borrowed and proven models may not have this problem, but then the challenge often becomes dislodging established competitors.

A plausible model may overlook several factors and make reasonable, yet untrue assumptions. For example, EuroDisney assumed that European consumers were essentially like American consumers, but they weren't. The result was many years of losses, until they adjusted their business model. Sometimes luck will reveal a totally unforeseen opportunity. For example, when Ford built their first SUVs, they saw it as an opportunity to make a small profit, but the Ford SUV factories turned out to be the most profitable in the whole company.

It's wise to adjust the business model as circumstances dictate and not get wedded to the initial model. Business models should be flexible and built for change, especially in volatile industries.

An effective strategy needs to accompany the business model. For example, Microsoft has a great business model, but a new entry has essentially no viable strategy to successfully adopt the same model. On the other hand, there are viable business models and strategies that allow a company to compete in the IT consulting market.

What is a Business Model?

An Enterprise Architect needs to understand the business model of the enterprise in which they are involved. The business model will often constrain what type of systems will be built and how they will be used. For example, an airline which offers low fares, frequent flights, no food and operates only point to point will have quite different IT needs than a full service airline that uses hubs, manages a complex logistics chain and offers air miles to their customers.

A good business model is the cornerstone of a successful enterprise. The business model answers the question, who is the customer, what does the customer value and is willing to pay for and how is money made from that customer?

The most powerful business models create whole new demand because they produce value in a way that no other business does. The source of value is either in the product itself, or the way in which the product is built or delivered to the customer.

For example, the Local Area Network created whole new categories of demand. It was a new product when it first became available and created demand for something that hadn't existed before.

On the other hand, companies like Walmart take an existing product set and revolutionize the way in which the product is delivered. Walmart makes money by among other things, running a highly efficient supply chain.

A company that is introducing a new business model, usually does not have the time to optimize all the elements of that model, they need to act fast to head off competitors. This means they need to build IT infrastructure that works fast, but may not be very good architecturally. The EA needs to recognize this and get a solution that satisfies the immediate needs without becoming an albatross at a later time.

In most cases, the Enterprise Architect will be asked to incrementally improve the operation of the business model. For example, a system that was created quickly in a prior era to address an immediate business opportuinity, may now be a serious drag on productivity. The EA needs to recognize this and replace an imperfect system with a much better one.

Dependency Inversion and Mocking

Any non-trivial routine or class usually has two type of interfaces the incoming interface and the outgoing interface. The incoming interface is part of the class definition, and therefore well understood. The outgoing interface is not formally defined in the class interface, and it consists of the methods a class calls on other objects. A poor job on the outgoing interface will create poor code, even if the incoming interface is well designed. To avoid this, the code should use dependency inversion.

Dependency Inversion is defined by Robert Martin as

1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
2. Abstractions should not depend upon details. Details should depend on abstractions.

Mocking is a useful technique for helping to achieve dependency inversion.

Much code development starts bottom up, with the definition of small classes with limited scope. The classes are then composed into larger classes. This tends to create kitchen sink classes, with many capabilities, since the needs of high level classes are not really known in advance.

With mocking, you start with with classes that have large scope and start testing the design with interfaces rather than classes. The interfaces can be mocked and left unimplemented until the design is perfected. Only when the design is proven as useful, do you implement the interface in a class. This type of design process ensure that your classes remain lean, because you build them only to fulfill the needs of real clients with known requirements. One danger though, is the proliferation of small classes with small interfaces. Ideally you should aggregate interfaces to create one class that implements several related interfaces.

Business Architecture

The definition of a Business Architecture is a prerequisite to the definition of an Information System Architecture or Technical Architecture, when undertaking an Enterprise Architecture effort.

A Business Architecture requires understanding at some level:

- Business Vision and Mission
- Business Model
- Strategy, Objectives and Goals
- Legal Requirements and Constraints
- Marketplace Dynamics
- Business Policies
- Stakeholder Interests
- Organization Structure
- Geographical Distribution
- Decision Making Processes
- Functions (manufacturing, sales, etc)
- Roles, Competencies and Responsibilities
- Business Processes (Process Order, Bill and Invoice, etc)
- Measurement Systems (Balance Sheet, Profit and Loss, Cash Flow, etc)
- Capital and Resource Allocation

Processes are at the heart of Business Architecture, and detailed analysis therefore requires defining:

- Business Use Cases
- Collaborations and Orchestrations
- Event Flows and Traces
- State Transitions
- Material and Information Flows
- Rules and Constraints

The analysis must be performed for the current state (the baseline architecture) and the future state (target architecture) of the business. Since the future is uncertain, it may be necessary to consider more than one target state. Effective transition planning requires understanding both the current and target states.

The effort to define a Business Architecture can be very large. One way to limit the time and cost required, is to avoid completely defining the baseline, as-is architecture and focus on the target state and on areas where there is either a significant shortfall or where rapid change is anticipated.

The description of the Business Architecture barely scratches the surface. The individual activities require much more detailed descriptions in order to be useful.

More in future posts.

Are Enterprise Architects Control Freaks?

Most Enterprise Architects, almost by reflex, recommend that infrastructure, data, applications and everything else be consolidated and centralized. In other words, Enterprise Architects often act like control freaks, who demand that all diversity and local control must be suppressed, in the name of Architecture purity.

There is one overwhelming reason that architects do this, it is to reduce complexity. In most corporations, IT has gotten out of control and there are way too many systems doing very similar things. So, of course, the first thing most architects do is recommend that systems be pruned and consolidated as much as possible.

But there is something that is often forgotten by these architects. It is the tension that exists in every business between those who want to centralize business operations to realize efficiency and economies of scale and those who want to decentralize to allow local autonomy and local accountability.

Centralization of infrastructure, data and services, although it often leads to greater efficiency, often results in loss of service and loss of control to individual Business Units. You see, fragmented systems often happen, because a BU sees an opportunity and commissions a system to fill that opportunity. This is not an ideal way to build systems, but at least systems get built and they deliver business value. Now, if the architect's control tendencies are successful, new systems will have to go through some sort of central authority, or coordinate with other projects which use the same resources. This almost always means that systems are harder to build because much more coordination is required and more approval steps have to be passed. The BUs are now in many respects worse off. Perhaps the total cost of systems has fallen, but so has their ability to get service.

Local autonomy is essential in most businesses. Architects who forget this, are not serving their business, they are creating an over centralized structure which cannot deliver services to the front line units.

Theories of Production

According to Koskela , there are three production theories for creating products and services:

1. Transformation
   
2. Value generation
3. Flow

The transformation theory, which is based on input, process and output (IPO) is the dominant production theory in use today. It is reductionist, it breaks down every process into individual tasks performed by specialists. Activities are tightly organized and controlled; it is consistent with Scientific Management and traditional cost accounting. It seeks to optimize the entire production phase by optimizing each individual task, assuming that minimizing the effort and cost of each task translates directly to maximum throughput and customer value.

Value generation focuses on delivering maximum value to the customer. All tasks and activities are measured and evaluated based on this concept. Activities that don't deliver value are not performed. Production efficiency is redefined as the efficient delivery of value to the customer. There is a strong focus on quality. If the customer does not want or value what is delivered, then activities that lead to these outcomes are considered waste. The theory is based on the assumption that a value focus will optimize the overall process of value delivery and lead to process optimization based on the larger context of value generation. The theory has a focus on quality, profits and ROI, not costs. Note that a process which transformation theory might consider efficient and successful, might be judged from the value generation point of view as a failure.

Flow is focused on realizing value quickly, minimizing inventory and reducing the total latency of production. Fast turnaround lets the market control what is wanted. Production does not occur unless there is a specific request for a product or a very strong expectation of such a request. Flow seeks to increase the tempo of production.

These three theories are very interesting and have many implications. For example, the Chinese economy is successful because it is a source of low cost inputs, maximizing value according to the transformation theory of production. The Chinese production model however, greatly slows down flow and can result in tremendous waste, since customer value is not a focus. By contrast, Japanese companies as exemplified by Toyota above all, focus on value generation and flow. These companies are not afraid to locate in high cost locations, because they know that the cost of inputs is not the only thing that is valuable to control. High cost locations are able to achieve faster flow and realize higher customer value (and therefore higher profits).

Recent data about China has started to raise questions about the performance of the Chinese economy. Chinese companies and operations are not turning out to be as profitable as might be expected, and companies in the Western world with high input costs, that focus on flow and value generation are able to compete with these companies.

Outsourcing of services is another instance, where these theories of prodcution have unexpected ramifications. Outsourcing is about reducing the cost of inputs and therefore reducing the cost of specific tasks, but flow and customer value creation are reduced, due to time lags, cultural issues and communication difficulties. On balance, outsourcing may not deliver the benefits its advocates expect and there are some indications that companies are starting to realize this.

Innovation, Risk and Throughput

Innovation is vital for business growth, and is a necessary activity of almost every organization these days. However, organizations often engage in activities which actually stifle innovation, because they don't understand the impact of innovation on their management practices.

Consider a company which has a heavy emphasis on high quality and high throughput in its production processes. Managers and employees are rewarded on their ability to produce, and produce with high quality. Now suppose that these same employees are asked to adopt an innovative but unproven procedure, which if it works will dramatically boost productivity. There is a problem though, the procedure is untried, it may fail, and even if it works there will be mistakes made. Now if compensation is based on throughput and quality only, then there will be strong resistance to adopting the new procedure. There may be the appearance of compliance, but in fact the same old processes will be used in order to get the expected throughput. The innovation will have been tried and found wanting, with no measurable positive results. Obviously however, the innovation was not tried, and now their is a false belief that this particular practice does not work for this company. This is a surprisingly common result.

This is a situation where the risk of failure is placed on the employees, rather than the company, where it belongs. The problem is that companies fail to alter their measurement systems to reflect the fact that innovation has costs. These costs should not be borne by the employees, but by the company.

To resolve this situation, it is necessary to alter standards to reflect the activity, effort and process, rather than the outcomes, and reward employees accordingly. At the same time, other groups will need to understand why standards differ from group to group. This is sometimes hard for organizations to do, especially if the culture of quality and throughput is ingrained in the organization's DNA.

To conclude, management innovation is often a prerequisite for product or process innovation. This is often forgotten in the rush to adopt the latest, greatest ideas.

Core Value and Core Competency

The concept of core competency has been a central idea of management theory for many years. The central idea is, that in order to gain competitive advantage an organization must focus its energies on the activities or tasks that will create the greatest customer value. This is the only way in which to generate sustained competitive advantage.

Essentially there are three ideas. First, find out what the customer values, this is what Geoffrey Moore terms core value. Second, organize your company and focus your energies around the activities or core compentencies that deliver core value in the most efficient and effective way possible. Third, leverage core competencies to deliver more core value over time.

This conceptualization closely ties core value to core competency. And clearly, core value comes first. What often happens however, is that organizations will incorrectly place core competency ahead of core value. Companies assume that customers will value that which they already do well. It is a very easy, but dangerous mistake to make.

This happens because all core activities which generate superior value are eventually matched in the marketplace and become what Moore calls context, necessary but not worth a marketplace premium. The force that over time makes core activities into context activities is powerful and cannot be readily stopped. Activities that may have been core, eventually become context. Organizations are structured to deliver not only core but context activities. Groups who may have once been prime movers in core value delivery, but who are now engaged in context activities are not usually willing to recognize this, and give up power and resources to groups focusing on core activities. This is one reason, large corporations often fail, they lack the ability to adjust their core compentencies to deliver core value.

Sign On or Sign Off?

Sign off is the terminology used in many corporate IT departments to signify that project planning, requirements, design, testing and other deliverables have been approved by stakeholders. Sign off implies a hand off of responsibility from party to party and a binding contract with rights, obligations and if necessary, penalties. It often creates an adversarial mindset, and implies some distrust and suspicion.

An alternative terminology is sign on. Sign on is about creating a shared understanding and creating a commitment to reaching common objectives. It is about shared responsibility and accountability. Sign on borrows the idea from contracts that precisely defined expectations and relationships are important, but avoids the trap of using a contract as a club to force parties to live up to agreements. Sign on promotes cooperation, not confrontation.

In many companies, sign on is in fact the common practice, but sign off is the terminology used. To reflect what is actually going on, the term sign off should be used for agreements which are 'binding', and the term sign on used for agreements where there is a shared understanding of common objectives.

Blogs and Learning Styles

People learn in many different ways. Some people learn by listening, some by reading, some by watching, some by doing and some by writing. Some take a top down, big picture approach and some start with details and work up to higher levels of abstraction.

Learning is essential to success in most endeavours these days, so efficient learning is an important skill.

Blogs are often seen as ways to publish information, but for many, blogs are actually a way to learn. Blogs capture thoughts which may not be fully worked out and coherent, but that's fine, if a blog is seen as a thinking tool, rather than the final say on a topic. It should also be remembered, that editing often eliminates useful ideas, and free flowing unedited blogs often leave useful ideas in the text.

I confess that for me, a blog is a thinking, rather than a publishing tool. It allows me to capture some thought and express it. Most thinking evolves, and both the thought and the expression of the thought can change. A blog creates a useful point in time record of some thought, which can later be reviewed and revised.

Now of course, a blog is a public tool, and really you could easily write thoughts privately. However, a blog has a useful role in encouraging complete and coherent entries, since somebody might actually read your blog, and complain if the text is completely rambling and incoherent!

Decisions and Flat Organizations

Recent years have seen a movement towards flat organization structures. One of the reasons that this occurs, is that decision making in flat organizations is often better than hierarchical organization for the following reasons:

1. Its hard to get good decisions made within a reasonable period, if the information required to make good decisions is complex and difficult to make sense of. The domain experts are usually better qualified to make a decision in complex domains.
2. The decision maker is highly motivated to successfully implement a decision. As decisions pass down a chain of command, motivation decreases.
3. Decisions traveling down a long chain of command are often not clearly communicated. The shorter the gap between the decision maker, and the implementors, the more likely the decision will be communicated clearly.

Complex and fast moving environments in particular, require flat organizations. Firms in the technology and Internet markets are prime examples. The speed and quality of decision making in these markets has consequences which are large and immediate. Hierarchical organizations will simply fail against organizations where decisions are made by the front line experts who have the knowledge to make decisions quickly. This is one reason startups do so well in these markets.

When someone is responsible for both making and implementing a decision, their motivation is very strong. Its not necessary to offer many extrinsic rewards, the individual is self motivating. This is the reason it is wise to let people make their own decisions as much as possible. This implies as few management layers as possible.

When decisions are made, the decisions are communicated in two ways: overtly through instructions and covertly through incentives. There are a couple of issues here. Most companies and their managers fail miserably at telling their employees what they want. Most employees end up guessing what they should do. The real motivators are pay incentives and potential promotions. However, actual incentives don't always line up with the intent of the decision. Incentive schemes can be 'gamed' or manipulated to get the rewards without fulfilling the intent behind the incentive. Stock options for executives are a prime example. Boards were trying to motivate executives to increase long term shareholder value, but CEOs ending up increasing the short term stock market price instead.

This is quite a deep and complex topic, which can't be covered in such a brief note. More, in future posts.

Decisions - An Event or a Process?

Decisions are usually either an event or a process.

When a decision is an event, it is simply announced and the expectation is it will be carried out without debate or discussion. The decision tends to be final.

When a decision is a process, discussion and debate are welcome and encouraged. Decisions are subject to change and adjustment.

When a decision is an event:

• Works well when immediate action is required or when the issues are clear cut.
• Can be bold and decisive.
• Can result in highly innovative decisions.
  
• Emphasis is on follow through rather than adjusting course.
  
• Consistent action is what is required.
• The letter rather than the spirit of the decision is rewarded.
• Accepting and implementing the decision is a sign of loyalty. Loyalty is rewarded and disloyalty punished.
  
• Those implementing the decision have low intrinsic motivation. Extrinsic motivation or rewards may be necessary to motivate action
• Debate is not welcome.
  

When a decision is a process:

• Buy-in from participants is very important.
• Intrinsic motivation tends to be high from participants.
• Decisions may be delayed while input is gathered.
• Decisions may change as more participants are engaged.
• Favorable results may be required early, to avoid reopening the decision.
  
• There may be confusion about what the decision is.
• Decisions may be timid as a result of compromises which attempts to satisfy all constituencies. Decision by committee.
• Group think may occur.
• Destructive rivalries may emerge as different groups jockey for a favorable outcome.
  

Note that in the above discussion, the correctness or wisdom of the decision is not that important. Its the way in which the decision is arrived at and announced that matters. This is a shocking statement to those readers who value the correctness of decisions.

Its very common for professional people (engineers, analysts, programmers) to debate decisions which are not in fact subject to further debate. This is a career mistake. Avoid it. Save your arguments for when you are asked for your input. In many organizations, you will only be asked for input, once you've demonstrated loyalty.

Some organizations never let their front line or mid level people inside the decision making process. If you work for such an organization, my advise is to rise quickly or get out quickly, otherwise your lack of access to decision making authority will likely drive you crazy if you have any ambition.