Tag: Bob Lewis

Bob Lewis on IT Projects, Part 2

In the book, There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change, Bob Lewis and co-author Dave Kaiser analyzed and discussed the new ways of thinking about IT and business management.

These are some of my takeaways from reading the book.

In “The New Business/IT Conversation” chapter, Bob and Dave outlined three types of business change that can benefit from better information technology. They are 1) business function optimization, 2) experience engineering, and 3) decision support.

Business function optimization is about getting the work done and done better. Experience engineering is about improving the experience everyone has when getting the work done. Decision support is about helping decision-makers make more effective decisions. Facilitating and making these types of business change happen should be the standard of competence for all IT organizations.

For IT, the question we used to ask was, what does the business want the software/system to do? The new question IT should be asking is how the business wants to do its work differently and better?

Business processes (how the product/service gets put together) and practices (the organization’s knowledge and experience) are different. They are the two poles of the continuum of how the organization gets its work done. IT should help a business figure out where on the continuum a specific business function should be placed to better design a system that can support it.

IT can help businesses better design their function only after understanding the input and output required by the business. The input and output are further influenced by six optimization factors: fixed cost, incremental cost, cycle time, throughput, quality, and excellence. It is not possible to optimize them all because there are constraints and trade-offs.

Designing external customer or internal user experience is complicated. Bob and Dave suggested IT start by setting this goal: “make their experience as un-irritating as possible.”

Finally, designing a decision support system is pointless until the organization adopts a culture of honest inquiry. Decision support systems are valuable only to the extent they reinforce this culture.

So, what can be done to address the new business/IT conversation? Fortunately, Bob and Dave have some solid suggestions laid out at the end of Chapter Two. I highly recommend the book.

Bob Lewis on IT Projects, Part 1

These are some of my takeaways from reading the book.

The whole point of the book is that our approach for implementing and managing information technology projects has been wrong. There is no such thing as an IT project because what we are trying to do is to achieve an intentional business change with the help of information technology.

When we try to achieve business transformation or change via an IT project mentality, we often set ourselves up for disengaged stakeholders, low return from the investment, and, more often than we like to admit, outright failures. When organizations implement IT projects, we create a situation where IT and the business can point the finger at the other and give themselves an excuse for anything that can go wrong.

The first thing to do in changing the IT project mentality is to change the organizational culture.

Culture can be explained as “how we do things around here.” Culture is the combination of our attitudes, shared knowledge, expectations, and values expressed in a common but specialized vocabulary.

Culture can also be expressed in terms of the employees’ learned behaviors in response to their environment. The standard operating procedures do not adequately articulate the organization’s culture; however, culture is the unofficial policy manual.

The culture change of No-IT-Project cannot be done via proclamation but rather with influence. The culture’s influence also flows from the top down the organization. For the leader to change her organization’s culture, she must lead by example.

Because culture defines “how we do things around here,” successful, intentional business changes can only come from a shared focus on the desired business change. If the organization’s culture is to treat business changes as departmental projects, the No-IT-Project movement is unlikely to take hold.

Because many organizations view the IT and business relationship as technology supplier vs. internal customers, it is very difficult to build a closely collaborative relationship on a transaction-oriented foundation. The customer-supplier relationship encourages silo-like thinking and might be the biggest barrier for moving towards the No-IT-Project and intentional business change approach.

So what can be done to address the culture obstacles? Fortunately, Bob and Dave have some solid suggestions laid out at the end of Chapter One. I highly recommend the book.

Communication Plan

In the book, Bare Bones Change Management: What you shouldn’t not do, Bob Lewis explained the seven must-have elements for any change management effort to have a chance of succeeding. Here are my takeaways from one of the topics discussed in the book.

A communication plan is the planned approach to deliver information to the stakeholders. The information communicated by the plan should help to bring an accurate reduction in uncertainty.

Bob recommended that the following elements should be addressed in the formal plan.

Triggering Event: This is the matter that is driving the need to communicate, whether it is a project milestone or simply the passage of time.
Audience: The individual or stakeholder group that is the target of communication.
Key Issues: The WIIFM factor (“What’s In It For Me”) or whatever we think each stakeholder will care enough to listen or to act.
Desired Outcomes: Form follows function – bottom line up front.
Document/Meeting/Agenda Topic: If it is an e-mail, it is the Subject. If it is a report, it is the Title. If it is for a meeting, it is what we would call it on the appointment calendar.
Vehicle: The communications medium we will use for each stakeholder.
Messages: The key, take-away messages we will deliver to each stakeholder.
Assignee: Spell out who is responsible for delivering the communication.
Date planned: When we want the communication to happen.
Actual date: The date when the communication happens.

When we are trying to change an organization, we will be under constant stress. The stress and fear will likely result in people to communicate less. The best way to fight this lack of communication is to include communication tasks in the project plan.

Without communication, the other six components of business change management (Stakeholder Analysis, Involvement Plan, Metrics Plan, Structure Plan, and Culture Change Plan) will not make much difference at all.

Culture Change Plan

Bob defined the word “Culture” by borrowing a definition from the field of Cultural Anthropology. Culture is the learned behavior people exhibit in response to their environment. In an organization, culture essentially is how employees respond to their environment, which means every organization has a culture.

Bob suggested practicing the art of describing every cultural trait in both positive and negative terms. With very few exceptions, cultural responses are neither good nor bad in any absolute sense. Mostly, they are good fits for some circumstances; but they can also be bad fits for other circumstances.

The first step in changing a culture is to characterize the culture. Bob believes there are seven situations where the organizational culture matters:

Crisis
Externally identified performance issue
Internally identified performance issue
Day-to-day work
Work style
Problem analysis
Loyalty

An organization will usually respond to each situation in two ways, positive and negative.

The second step of changing culture is to designate which cultural traits matter for a change, and how the participants must change. Again, the organization leaders will have to look at all seven situations above and determine what desired cultural response is required to support the change.

Since culture is the learned behavior employees exhibit in response to their environment, Bob believes that organizations can better manage their change initiative by managing the following environments effectively.

Physical environment
Communication environment
Leadership

It is critical for an organization to determine how leader behaviors have led to the current culture, and how it must change to encourage the desired culture.

Training Plan

When the subject is business change, a training plan qualifies as an assumption, not just an opinion or a “nice-to-have.” Everyone needs to understand their role in the change, and they need to have a common understanding of the shared expectations.

Bob offered the following recommendations for pulling together a training plan.

Engage the professionals early
Don’t let the training professionals sell employees short
Show employees how to do their jobs, not how to use the tools
Provide context, not just job-specific skills
Do not neglect brand training
Train just in time
Tailor training to the level of aptitude and confidence
Certify knowledge and skills
Provide floorwalkers or triage centers
Don’t assume you did it right

In addition to training people to adapt to the change or use the new tools, Bob pointed out some additional items.

One, develop a transition plan. While the training plan often describes the to-be environment, the transition plan will bridge the gap between the present as-is and the new to-be situation.

Two, have coping skill training for the managers. Train the managers to help their employees cope with the change. Not everyone will move through the stages of change at a uniform pace. The managers need to understand the dynamics within their areas and possess the skills to help their group implement the change.

Three, train the stakeholders. Rarely a change impacts only a handful of individuals. The organization needs to evaluate the pending impact on the stakeholders and to train/educate them about the change.