Business-Oriented IT is a Competitive Advantage

Alignment with business customers is an incredibly hot objective for technology strategists and one that is supported by powerful long-term market trends. I have argued that the line of thinking which IT and the "Business" are not one component does not add any value to the firm and one which will need to be overcome.  A recent survey by Forrester Group of strategy professionals found that 91% of respondents say that increasing their business focus is a strategic priority for their organizations over the next three years — beating out other hot topics in the technology industry such as innovation, investment in social emerging technologies, mergers and acquisitions (M&A) activity, and geographic expansion. Despite the strong interest, however, I find far too many technology companies see this objective as primarily a responsibility to be handled by marketing organizations. To prepare for the long-term evolution of the technology industry with the business, technology firms will need to take a much more robust approach — one that incorporates the needs of business customers into product development, strategy, marketing, and sales.

INCREASED BUSINESS FOCUS ALIGNS WITH IMPORTANT NEAR- AND LONG-TERM TRENDS
I hear from many technology companies that say that they want to improve the way they are aligning their technology products and services with the needs of business customers. These companies have realized that fundamental shifts are taking place within traditional IT departments: IT decision-makers are no longer the sole owners and drivers of technology purchasing decisions, and business leaders increasingly expect vendors to highlight the business issues that technology can solve. This interest is consistent with two key trends I see that will be critical to the success of strategists in 2010 and beyond:
The economic downturn has changed the way technology purchases are made. In the past year, many tech companies have tried to become more business-focused as a way to counter the effects of the recession. With more stakeholders weighing in on technology purchasing decisions and longer purchasing processes existing, tech vendors are selling to business stakeholders as a way to cut through red tape and quickly close deals.
The technology industry is becoming embedded in the business process. Increasing technology alignment with business needs is consistent with the long-term evolution of the IT industry. As technology becomes a more integral part of business process, IT organizations are under greater pressure than ever to keep pace with the challenges their business customers face. In the long term, this trend is shaping what technology vendors sell, who they sell it to, and how they sell it.
The problem for most technology vendors, however, is that when it comes to business focus, everyone talks about being good at it, but few are really executing. Although virtually all tell us that business focus is their priority, ask them what they are doing to execute on that priority, and responses vary significantly. Some vendors have adjusted their strategic plans and market outlooks drastically, others have just made adjustments to their marketing messages, and still others have difficulty explaining what their "business focus" means at all. For most part, it seems that the tech industry is still rooted in its heritage of serving IT customers. I has instilled in their service model a process to determine if a vendor actually is executing business focus.

ALIGNING WITH BUSINESS HAS BECOME A KEY PRIORITY FOR MANY
In previous research, I have identified how several companies are investing in business-focused messaging strategies at the corporate level — but the marketing of individual product and service offerings lag behind corporate ambitions. This disconnect can be symbolic of serious gaps within organizations: When corporate leaders move faster than the sales and marketing professionals, customers may be left with mixed messages. I believe that technology vendors need to do more to incorporate their business focus at all levels of their organization.

MARKETING STRATEGIES ARE THE MAIN TOOLS TO FOCUS ON THE BUSINESS CUSTOMER
We found it concerning that the most top-rated tactics of focusing on the business customer are all generally related to marketing and sales, while the lower-rated tactics relate to products, services, and evaluation metrics. While this could reflect the marketing focus of many of our direct partners, it also highlights a trend I see: For many technology companies, interest in business focus is largely perceived as a marketing tactic, rather than an area for complete strategic alignment. In this regard, companies that differentiate themselves are the ones stressing the importance of business alignment in their product development, strategy, marketing, and sales.
It's also noteworthy that use of metrics often ranks relatively low on this list of tactics. This highlights the fairly common difficulties that companies have when seeking to provide something as vague as business value, without having a fully developed understanding of what it means. Although we often hear from vendors that say that providing business value to their customers is best highlighted in the cost savings they provide, reduction of IT costs is a metric that is rooted in an IT-centric view of the world. Business leaders care about costs, but they also care about diverse factors such as improved customer satisfaction, levels of innovation, and time-to-market. This highlights an opportunity for vendors to get closer to their customers by identifying their success metrics and working with them to achieve those metrics.
LINE-OF-BUSINESS AND C-LEVEL EXECUTIVES ARE THE TARGET AUDIENCE
When we asked our customers about the business roles they are targeting, we found that line-of-business managers are being targeted as the primary business customer. Next in line were C-level executives such as chief executive officers (CEOs) and chief financial officers (CFOs), followed by chief marketing officers (CMOs) and individual contributors.
It's not surprising that line-of-business managers are the most popular target. They are much easier to access than C-level professionals and often have the budget authority to push technology decisions. Just as importantly, these are the stakeholders with the most immediate business technology needs. For vendors, this data point highlights a major opportunity: Business professionals are increasingly aware of the strategic value of technology, but their IT organizations are not meeting their needs. Vendors that want to improve their strategic relationship with their customers need to do more to identify and meet these needs, even if it means making fundamental changes in traditional marketing and sales channels.
The focus on CFOs is also interesting given the increasing alignment between IT and finance. As IT organizations face greater operational scrutiny, it's not uncommon to see CFOs making

My Approach
Unfortunately, many technology companies don't know what they are up against when they say that they are going to target business customers with their technology solutions. Companies that have traditionally sold to the IT organization will find it extremely difficult to make the jump into selling to the business audience because the core needs of these audiences differ so significantly from those of a traditional IT buyer. Although we agree that tech firms need to carefully incorporate the needs of business professionals into their marketing and strategy, technology firms need to manage these efforts carefully, invest in the right areas, and be prepared to make their efforts part of a long-term endeavor. At a high level, companies should consider how they align in three areas other than marketing:
Strategic support. Targeting business customers’ needs to be part of a broader strategy that brings in the right people with the right business skills. Companies usually do no develop their base of C-level relationships overnight — they invested heavily in a partner-driven approach that is supported by robust thought leadership and fundamentally linked to the way they do business.
Product value proposition. Targeting a C-level executive may make sense but must be relevant to the stakeholder in question. I have identified ways to evaluate the needs of IT buyers, line-of-business buyers, and senior management. If you expect your technology solution to resonate with the business buyer, the core value proposition should be aligned with his or her needs.
Sales alignment. The effectiveness of a business focus in marketing efforts must also be supported by a robust sales strategy. Making a shift from an IT-focused sales approach to a business-focused sales approach does not happen overnight. The content used has to be compelling and relevant to a specific business need, greater emphasis must be placed on the business objectives achieved, and measurable objectives must be outlined. Just as important, the sales force needs to be sufficiently supported to cope with the added time and effort required to invest in business-level relationships.
These three areas should highlight the challenge that many companies will face as they try to transform their technology companies from IT-focused to business-focused. Despite the time and investment required, however, there is tremendous opportunity for companies that can do this well. As noted, business alignment is consistent with near-term and long-term market trends — meaning it should increasingly be viewed as a key component of strategic planning.

How Budgets Ruin Value Creation and Delivery

Everyone has to deal with budgeting.  Budgeting is simply the process of determining how to fund your expected needs in a project.  Budgeting is not a process with an extensively long history.  Much like most modern management it is a function of how organizations with tremendous growth planned spending. They determine how people behave in any given situation. Focusing leaders' minds on the stewardship of shareholders' funds and ensuring that managers worried about controlling costs were its original functions, and leaders and managers, by and large, behaved accordingly. But budgets have since been hijacked by a generation of financial engineers that have used them as remote control devices to "manage by the numbers." They have turned budgets into fixed performance contracts that force managers at all levels to commit to delivering specified financial outcomes, even though many of the variables underpinning those outcomes are beyond their control. This leads to undesirable and, in many cases, unethical behavior.

How has budgeting and the finance process stiffed innovation to the extent where over 90% of professionals look at budgets in negative terms.  Why is there not more outrage regarding how the process denies agility?  Lean and agile models work towards delivering value while adapting to changing business needs.  I believe there is nothing more threatening to an agile and lean process then the limitations set forth with a budgeting process.  When budgets are calculated to forecast something a year to six months out how can this possibly foster value creation? Budgets are a modern day contract where the budget contract is usually fixed for a period of twelve months. Its purpose is to commit a subordinate or team to achieving an agreed-upon outcome and then to enable a superior to control the results against that outcome (reserving the right to interfere and change the terms if necessary).


How have we arrived at such high levels of dissatisfaction with budgeting? There are three primary factors: (1) Budgeting is cumbersome and too expensive, (2) budgeting is out of kilter with the competitive environment and no longer meets the needs of either executives or operating managers, and (3) the extent of "gaming the numbers" has risen to unacceptable levels. Few senior executives seem to be aware of these problems. They see outcomes in terms of numbers rather than behaviors. In this context, budget contracts can act like drugs. They seduce executives into believing that they have control over their future financial outcomes. But, like most drugs, they have serious side effects. They lead both senior executives and operating managers into an annual performance trap from which it is difficult to escape.


In these turbulent times the budgeting process struggled to cope. Goals and measures were internally focused. Intellectual capital was outside the orbit of the budgetary control system. Innovation was stifled by rigid adherence to fixed plans and resource allocations agreed to twelve to eighteen months earlier. Costs were fiercely protected by departmental managers who saw them as budget entitlements rather than scarce resources. The internal focus on maximizing volume collided with the external focus on satisfying customers' needs. And far from being empowered to respond to strategic change, front-line people found that it was easier to do nothing than to try to get multiple signatures on a document authorizing a change in the plan.


The organizations I have worked with used to set targets on the basis of financial numbers that, more often than not, were negotiated between superiors and subordinates before the start of the year. These numbers were fixed for the year ahead and represented the key component of the annual fixed performance contract. All actions were then focused on meeting the numbers not on value delivery. However, whether this process maximized the profit potential  is doubtful given the desire for superiors to stretch ambition and the desire for budget holders to play safe.


What does the Lean Technology Transformation do to solve this?  Well it's not so simple but here are some ideas.  What holds your organization together is not a plan, but a commitment to a clear purpose and to a set of clearly articulated principles and values.  To create value intellectual capital needs to be set free from stifling bureaucracies, free from the restrictions of predetermined plans, free from the fear of failing to meet fixed targets, and free from the forced cross-company actions designed by central planners.  Agile leaders set targets based on high-level key performance indicators (KPIs) such as return-on-capital, free cash flows, or cost-to-income ratios. Goals are typically set at levels aimed at maximizing short- and medium-term profit potential at every level of the business. Managers are willing to accept (or propose) these stretch goals because their performance will not be evaluated and rewarded against them. They will subsequently be measured and rewarded using a range of relative indicators such as peer group performance, internal and external benchmarks, and prior years' results. "Baseline" goals set a lower reference level of expectations. Though goals are primarily financial at the highest level, they become more operational the nearer they are to the source of value delivery.

By making this transition The benefits are that the process of setting targets is fast (days rather than months) and because it is based on relative measures it will seldom need to be reset. Also, because the benchmarking bar is always being raised, it is more likely to maximize profit potential. Some project leaders figure they have saved 95 percent of the time that used to be spent on budgeting and forecasting. This time is more usefully spent on planning how to create more value for customers and shareholders as well as how to respond more effectively to change.

Changing to a more updated model fundamental matches the goals of a lean organization.  The impact on the behavior of front-line people must not be underestimated. It leads to what Harvard professor Chris Argyris calls "internal commitment." The hidden problem, according to Argyris, is that people have to deal with two types of commitment. First, there is external commitment, which, by and large, leads people to fulfill contractual obligations specified by others, and in which performance goals are top down. Second, there is internal commitment, which allows individuals to define their own plans and the tasks required to fulfill them, and which is participatory, comes from within the individual, and leads to people taking risks and accepting responsibility for their actions.This is the behavior that the relative improvement contract seeks to encourage. The rhetoric of leaders does not produce internal commitment any more than it leads to effective empowerment or personal responsibility. Such changes require a fundamental change in the process that determines the behavioral context.

Finally, what needs to happen in the firm is a decentralization which enables leaders in your high performance teams.  Below are six common principles which organizations who have made this break posses:

1. Built a governance framework based on clear principles and boundaries
2. Created a high-performance climate based on the visibility of relative success at every level
3. Provided front-line teams with the freedom to make decisions that are consistent with governance principles and strategic goals
4. Placed the responsibility for value creating decisions on teams
5. Focused teams on customer outcomes
6. Supported open and ethical information systems


The leaders in question have abandoned the notion that employees base their commitment on mission statements and detailed plans prepared by someone else. They have abandoned the command, compliance, and control approach that assumes that strategy formulation and execution take place in separate compartments. And they have abandoned the assumption that front-line managers cannot be trusted with the responsibility to think and act on the latest information in the best interests of the firm as a whole. They have built a relative improvement contract based on mutual trust, with clear responsibilities for high-level performance from front-line people. They have also built a community spirit that reflects the interdependence of the organization and that supports seamless solutions for customers. Above all, they have recognized that people respond more positively to clear values and principles than to nebulous mission statements and detailed plans.

The Informal Insurance Policy

"Why is this not what we asked for?
This is what you asked for.
No it's not.
Yes it is!
No it's not!
Look at your documentation it's just like you asked for it!
I never signed this document!"

How many of us have had discussions like this in our organization? How did documentation become the insurance policy between the business and IT?  Why is it that a signature on requirements documents are never completed until the last minute in the project?  Of course we all know why, regardless if we will ever publicly disclose it.

Okay I will spill the beans, it's because everyone reserves the right to change it up until the last minute before delivery.  They reserve that right because they often don't know what the customer wants or IT does a poor job delivering what the business wants. By holding documentation hostage, business and IT will use that document as an insurance policy.  Some call it CYA while I just say it's creating an environment of tremendous waste.  Often in organizations the collaboration between IT and the business (yes most of you know I hate that phrase) is so tense that a requirements documents is used as a mechanism to cover your backside.  Agile's answer is customer collaboration over contract negotiation and/or working software of comprehensive documentation.   Lean likewise is similar with focusing our energy on delivering customer value over wasteful activities.  These philosophies have taken a distinct position against unnecessary documentation because they know it prohibits collaboration and any resemblance of value based delivery.

The majority of organizations believe that documentation is the collaboration tool which delivers the right solution to the customer.  This rarely is true if ever and I often see when consulting a client that documentation is used as a reason (or excuse) not to deliver value to the customer.   For those of you who as an organization live and die by documentation ask yourself, what real value does documentation serve in my job?  Does it serve as my professional insurance policy?  When does the document get signed?  Why does it even need to be signed?  What purpose does a signature even serve?  How often is the document used as a device of threat and intimidation?

I'm not suggesting that there is no need for documentation as I believe there's plenty need in plenty of activities.   Arguably though I believe 90% of the perceived need disappears when organizations value stream their process and measure if it's delivering value to their customer.  Documentation is an important part of any organization, but unlike traditionalists who often see documentation as a risk reduction strategy, value based delivery sees documentation as a strategy which increases overall risk the more emphasis placed on it.  The answer is simply to write documentation when that's the best way to achieve the relevant goals.  Question what those goals are though that require documentation that ask for signatures or are used as clarification.  If documentation is being used in place of collaboration then you should be worried as an organization. 


If you're organization is heavy in documentation I would like to hear from you.  Is the reason you document to act as an insurance policy?  If it's an insurance policy how is trust viewed in your environment?  How is your relationship with other business groups?  How often does your customer accept your first pass as acceptable? How does your organization understand the concept of value delivery?  My experience tells me that if any of these questions are answered in a negative light then you are document process intense.  Likely if you are document heavy then you work in a command and control environment with contentious relationships.  If you work in a trusting environment where the distinction between you and other business units is blurred and you have a great collaborative relationship with your peers then I will go out on a limb and propose you have limited documentation.  Environments of trust create minimal documentation.  Which environment do you work?  I'm interested to hear how your firm uses documentation and how you collaborate.   

Agilepalooza July 15th

I will be speaking at Agilepalooza in Chicago July 15th.  If you're in Chicago please come visit me.

http://www.agilepalooza.com/Chicago2011

Does Agile Consider Value?

Lean process has an exceptional focus on providing value to the customer. Always when an action is considered we ask ourselves "Would the customer be willing to pay for this?" I've often seen when groups are considering an agile transformation they are focusing on faster iterations, but faster iterations of what? An agile team can certainly deliver faster iterations of what the customer doesn't want. Often many poorly run teams do exactly this. For this blog post I would like to consider three elements which I believe can foster the value perspective when creating user stories.


User stories are not a highly documented series of requirements but rather a reminder to collaborate about the topic of the user story—in other words, in agile development (good agile at least), the documentation is secondary to the collaboration. The intent of user stories is to foster collaboration; the perspective is on customer value. If your user stories look more like requirements in disguise, you need to worry less about what specification you are using and more about how to increase collaboration. If, on the other hand, you have a collaborative environment already, user stories will enhance the collaboration more than use cases and traditional requirements can, in which case user stories are a better tool for you.

There are three main problems I see in stories. First is too much information in the description. This leads to a loss of collaboration and a reliance on the old ways of documenting everything. A user story should be thought of as a "talking points", a "to-do list," or a "tickler that a conversation must occur about a topic." The user story is a placeholder for a conversation or series of conversations: it is only through collaboration that a user story works as an agile tool; otherwise it's just a requirement written on an index card.

Too much information in a description can lead to the second problem: missing information in acceptance criteria. Before agreeing to work on a story, the team must understand the acceptance criteria. These are essential for knowing what needs to be done in order to satisfy the user story. Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to quash collaboration. Writing acceptance criteria should not an afterthought – it is a crucial part of a user story.

The third problem is to confuse acceptance criteria and test cases. Both are necessary for a user story. Acceptance criteria answer the question, “How will I know when I’m done with the story?” Test cases answer the questions, “How do I test and what are the test steps?” While both acceptance tests and test cases should be added to the user story via collaboration, only acceptance criteria are required. Test-driven development is often used to flesh out the test cases as the code is written.
Comparing User Stories, Use Cases, and Requirements
The basic difference between user stories and other forms of requirements specification has to do with perspective and intent, both of which affect the level of detail.

Traditional requirements’ perspective is on system operations. They are typically written with the intent of limiting interpretation. They rarely have tests or acceptance as part of the mix – that’s another document – and are often written by someone other than the requirements author. The level of detail can vary, particularly if those writing the requirements are using a hierarchical approach to drill down to successive levels of detail. Traditional requirement focus on what the system should do, not on the user or business workflow.

Use cases have the perspective of the users and their interaction with the system in mind. The use case diagram and associated text are intended to show the capabilities of the user and how these capabilities are met via a system response. Work flows or business flows can be derived from use case diagrams; the text of the use cases shows system and user interaction in a call-and-response format. Use case text typically contains more details than stories and traditional requirements. Test cases can often be written from the use case text, but are not typically part of the use case diagram per se.

Both traditional requirements and use cases are meant to be successively refined into greater detail through detailed analysis and design into. They are both written as the primary communication media for the system capabilities.

User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team. A user story is a metaphor for the work being done, not a full description of the work. The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. As such the level of detail of a user story is ultimately higher than a use case but lower than a traditional requirement. In order to limit scope, user stories have collaboratively developed acceptance criteria which define when the user story meets the stakeholder’s expectations. Test cases are often developed as code (with test driven development) or documented as the code is developed.

Comparison example
Problem Statement
The client has requested the ability to search for health care providers by provider specialty within a doctor selection site.

Sample Requirements Statement:
The provider search screen shall provide the ability to search for providers by provider specialty.

Sample Use Case
The client selects provider search.
The system retrieves a predefined list of provider specialties and populates the specialty list. The system displays the provider search mechanism.

The client selects a provider specialty and initiates the search.
The system retrieves a list of providers that match the provider specialty search. [Alt 1]
The system displays a list of providers that match the search. [Alt 2]
End use case

Alt 1: If there are no matches, the system displays a message indicating that no matches were found. End use case.

Alt 2: If there are more matches than the user can view, the system will provide the capability to display multiple pages.

Sample User story
Title:
Search for providers by provider specialty.

Description:
As a provider search user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.

Acceptance criteria:
The provider search mechanism has the ability to enter a specialty.
The specialty search will have a list of provider specialties from which to select.
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.


Conclusion
Are user stories better than other types of requirements specification? It depends. In the end, it’s the individual or team that makes a particular technique work (or fail). If a team is used to an iterative approach, use cases and user stories will be relatively easy to work with. If a team is steeped in waterfall and “big requirements up front (BRUF),” that team likely will bring that style to user stories and end up with traditional requirements that are user stories in name only. Adopting the underlying philosophy (concepts like collaboration and just-in-time requirements) is the key to moving toward more agile specification devices, such as user stories.

Agile Adoption Roadmap: Agile Value Capture Metric - Are you spending your...

Agile Adoption Roadmap: Agile Value Capture Metric - Are you spending your...: "When applying an Agile mindset, you should consider the value of each task that you are asking the Agile team to complete.   Agile often bri..."

Agile & Business: Lame Scrum Implementations

Agile & Business: Lame Scrum Implementations: "I was talking to a colleague about one problem, and then said, 'but this is not our biggest problem -- our biggest problem is lame scrum imp..."

Agile and Lean – Interview with Mike Orzen

This week we are exploring questions two of our interview series with Mike Orzen.  You may read the first posting of our series here.  Look for post four of our Leveraging Agile Principles in IT Operations next week. 

I have had a great opportunity to read Mike’s book Lean IT and recommend this literature to you regardless of you experience with lean.  The book was recently awarded the prestigious Shingo Prize for Research.

Mike Orzen delivers a unique blend of lean, six sigma, IT and operations. He has been consulting and coaching for over 25 years to companies in IT, manufacturing, aerospace, high-tech, medical device, healthcare, casting, legal, logistics, apparel, and food processing. His experience includes systems design, application development, numerous ERP implementations, enterprise-wide process improvement, and large-scale roll out of lean enterprise initiatives for global companies.  Mike is on the faculty of the Lean Enterprise Institute and teaches the LEI Lean IT workshop.

Question 2.  What do you see as the difference between Agile and Lean within IT?  Can they coexist?

Agile software development methods have transformed application development from lengthy waterfall-driven projects to rapid, iterative delivery cycles of usable functionality. Most of us are familiar with the benefits of Agile, and it has been well documented (see Poppendieck’s Lean Software Development: An Agile Toolkit), but there is still a gap between Agile and the Lean community. Often IT leaders do not view Agile as a key component of a Lean transformation.

Lean is a philosophy, a set of principles, and a tool kit for creating a highly effective organization. The principles of Agile, acknowledged in 2001 through the Agile Manifesto and supporting principles, identify a perspective on how the work of software development should be viewed. This outlook is very consistent with the core principles of Lean. Both Agile and Lean strive for high customer satisfaction, collaboration between producers and end-users, frequent deliveries, the smooth flow of value at a pace which can be sustained, high quality, respect for the individual and effective teamwork. In fact, Agile is often referred to as “Lean software development.”

Lean and Agile also share many tools including daily huddles, visual management, mapping, co-located teams (cells), small lot sizing (one piece flow), delivery synchronized to customer demand, level scheduling, kanban, and critical reflection.

So if Lean and Agile share so much common ground, why is there a lack of understanding and acceptance of Agile practices in many companies that practice Lean? I believe three factors contribute:

1.      A lack of knowledge and familiarity

Many of the organizations I’ve worked with have invested heavily in Lean education, workshops, improvement events (Kaizen events) and certification. The majority of these organizations don’t see a critical need to bring Agile into their companies despite the painful consequences of traditional (waterfall) project management used in their IT development.  Frequently, they just don’t understand Agile or are not able to embrace it. IT associates are often very familiar with Agile methods and will bring up the topic to their bosses, who may view it as another “tool” or something that “won’t work here.” Because they are unfamiliar with Agile and do not see it as complementing Lean, some managers reject it as something foreign, believing it will confuse people and undermine their emphasis on Lean.

2.      A lack of effective support and coaching

I often discover that this is the result of not having a champion within the IT group that has either the position power or the thought leadership to influence the decision makers. There is usually no one on staff with the experience to train and coach the team in Scrum or other Agile method. They attempt to apply Agile and get poor or modest results, and quickly toss it out and revert back to the old way of doing things. For Agile to succeed in any organization, it must be experience-based (learned by doing) and many organizations lack an experienced and qualified guide.

3.      “Sharpen the saw” syndrome

In 1989, Stephen R. Covey published the landmark book, The Seven Habits of Highly Effective People, in which he explores behaviors that lead to truly great results. Habit #7 is “sharpen the saw.” Covey uses the story of a person cutting wood becoming less and less productive using a saw that gets duller over time. The implied solution is to sharpen the saw, i.e., improve the effectiveness of the tool.

In IT, we often conclude that we do not have the time to slow down development activity long enough to “sharpen the saw.” With a huge backlog of projects, pressure to deliver functionality at a quicker pace, and the risk that the business will go rogue and simply purchasing a solution which IT will inherit support responsibilities for, we conclude it best to maintain our present course, knowing its shortcomings. Just like the woodcutter, we are too busy to take measures to improve our work methods and tools!

IT leaders that have invested the time to introduce Agile (often in small pilots so as to mitigate risk) often declare after introducing Agile: “We should have done this many years ago!” People respond when they are a part of a team that produces high-quality work which truly meets the needs of end-users. Pride in their work returns and a willingness to take on and overcome challenges reappears as the team gets on a winning streak. The entire tone in the workplace changes as people become energized and reengaged!

For an exploration of Lean IT and how Agile fits in a Lean organization, see Lean IT: Enabling and Sustaining Your Lean Transformation, recipient of the Shingo Prize for Research.

Leveraging Agile Principles in IT Operations:3 of 4

Customer collaboration over contract negotiation

Agile Overview

The last post in this series outlined how you can get your arms around creating meaningful documentation using the Agile concept of maintaining working systems over comprehensive documentation, starting with identifying how you will be using the documentation.

This week we’ll look at the third precept of the Agile Manifesto: Customer collaboration over contract negotiation.

Identifying the Customer

Identifying the customer can be more complex than it seems, particularly when your customers are internal, as they are for many IT operations teams. Numerous articles have approached the topic of the business as the IT customer. Basically, your customers include anyone who comes to you for help with any of the services you provide. They are looking for you to add value to their request. They have come to you with an understanding that you are the subject matter expert.

There may be dissention from the lean camp regarding who the customer is, but the customer in this case is the group that provides us with capital based on the value received. This article will focus on operations departments that only support internal customers.

Most companies have a set process by which internal customers may approach the operations team for services, often filtered through the helpdesk. Others have a more informal approach that relies on various types of shoulder tapping or other uses of informal methods. Another approach is to embed operations resources within project or product teams.

Whatever engagement model your organization uses, it’s important for your team to know how customers might contact IT operations and exactly what services you can provide them. Additionally, if your process requires more formalized methods it’s beneficial to ensure all participants of the process follow that process consistently.

The Contract Approach

IT service contracts are used extensively by consultants and 3^rd-party service providers for various business-to-business needs. They’re valuable for defining factors such as time, cost and scope. They also set expectations relative to those factors. The common reason why this contract exists is because a contract is a legal binding between two independent and separate organizations. Without a contract there’s not a legally binding method of recourse should a disagreement occur. Furthermore, a contract will help two firms define the roadmap of their relationship and can provide details on the formalized components of the agreement.

Similar contracts are cropping up increasingly often between IT operations teams and their internal customers. A low-level type of internal contract is the Service Level Agreement (SLA). While I fully support the idea of establishing SLAs, I believe that following more elaborate contracts internally takes the concept too far for an agile and/or lean organization. Internal contracts are a bad idea for several reasons.

Contract Drawbacks

First, internal contracts cause division between IT and the business. When one group within a company can stonewall another by refusing help because a service isn’t listed in the contract, or because the service doesn’t fit the defined role of the IT operations person to whom it was assigned, it damages both the business (because of delays) and the relationship between operations and other parts of the business.

Second, internal contracts can’t be enforced. If a breach of the contract occurs, neither party has legal recourse for the violation. A process that includes portions that lack power is wasteful, particularly if those portions also limit the work that can be done to support the business. If an organization lacks discipline to the point that it requires an internal contract to get work done, then there are deeper issues that need to be addressed. A contract is almost never the right answer.

Third, a contract limits collaboration and the spirit of teams. A team structure and hierarchy are less important then most firms believe. What’s important is to realize that a team needs to have the right skills and relationships focused on value delivery, not the right contract. When the disparate divisions in a company realize that there is only one team and we’re all part of it, the productivity of the organization can increase dramatically.

Focus on Value Delivery

Agile thinkers and most Lean fundamentalists tend to have very effective relationships with their customers because of their focus on process for value delivery. Focusing a team on the most efficient way to deliver value should take precedence over writing binding contracts. Often this can only be done when there’s trust between all members of the teams. Trust is the outcome that emerges when efficient teams focus on value delivery rather than roles and responsibilities.

Communication

If the information a communication practitioner receives is flawed in any way – be it false, misrepresented, misinformed, or inapplicable to specific goals – then the remainder of the process is irrelevant: the disseminated message will be flawed.

When you concentrate on efficiency, your organization’s methods of communication should be prioritized as the number one focus for delivering value between two teams. Start by determining the most efficient process for your teams and then decide how your organizational culture can support a communication process which is empowering and value driven.

Looking Ahead

In part 4 of this series we will examine how the fourth precept of the Agile Manifesto, responding to change over following a plan, supports an IT operations environment.

Jen Browne and Patrick Phillips

What is a Lean IT Organization? Interview with Mike Orzen

We will be back to part 3 on our Leveraging Agile in Operation early next week.  This week I have the honor to post the first question of many from an interview with Mike Orzen.

It’s difficult to find lean practitioners who focus and coach IT organizations well.  The reasons are many which may be the impetus for another blog but I have been fortunate to meet a great Lean leader for IT and healthcare.  I felt an obligation to share his knowledge with you and hope you enjoy his insight in to this topic as much as I have in my leanings from him.   

I have had a great opportunity to read Mike’s book Lean IT and recommend this literature to you regardless of you experience with lean.   

Mike Orzen delivers a unique blend of lean, six sigma, IT and operations. He has been consulting and coaching for over 25 years to companies in IT, manufacturing, aerospace, high-tech, medical device, healthcare, casting, legal, logistics, apparel, and food processing. His experience includes systems design, application development, numerous ERP implementations, enterprise-wide process improvement, and large-scale roll out of lean enterprise initiatives for global companies.  Mike is on the faculty of the Lean Enterprise Institute and teaches the LEI Lean IT workshop.

1.  Can you explain why IT has not seen a bigger movement in Lean, and what does it mean to be a Lean IT organization?

A Lean IT organization uses its information and information systems to enable the flow of value to its customers. IT systems are the connective tissue that coordinates most communication and execution of work throughout the value stream. A Lean IT organization applies the principles and tools of Lean to eliminate wasteful systems and processes to provide accurate and timely information to suppliers, employees, and customers. Above all, Lean IT organizations are comfortable with the inherent ambiguity of solving problems when solutions are not apparent.

In many organizations, IT is among the “last frontier” when it comes to applying Lean principles. Often we see Lean successfully applied to the shop floor in manufacturing environments and the front office (including HR, engineering, supply chain, and accounting) in both service and manufacturing companies, but IT is conspicuously missing from the Lean transformation. I after ask why and usually get one of three responses:

1)      IT is too busy, they have a multi-year backlog and don’t have the time to be pulled away to participate in improvement work.

2)      We don’t really see the need to bring IT staff into an improvement effort when we’re problem solving. We’ll tell them if we need a report or additional app functionality if and when the team makes that determination.

3)      IT staff are difficult to work with and best left with their heads down, coding software or deploying a new server!

These responses indicate a lack of understanding of the key role IT must play in effective process improvement. Although we all acknowledge that accurate information is essential to any business in creating value and flowing goods and services to the customer, we seem to think we can generate improvements with cross-functional teams that do not include IT associates. Let’s look at these responses one-by-one.

It’s true that, in many cases, IT does have a huge backlog which is only getting larger as a result of a) late delivery of projects and b) additional projects endlessly added the portfolio. Out of control IT backlogs are symptoms, not causes of conditions calling for improvement. By excluding IT from Lean improvements, we avoid the real issue (the root causes of the current condition). The fact that we view IT as being “too busy” to participate in Lean improvement is the best reason to involve them! Until we begin to move away from business as usually, we can only expect things to get worse: larger backlogs, more project overruns, and more frustration.

Having IT staff participate in Lean activities infuses Lean improvements with “systems thinking.” IT professionals are natural systems thinkers. Systems thinking is the ability to see the whole picture and not just a segment of the process. IT staff are well versed at seeing the entire flow of a transaction from data capture to final resolution (Seeing the Whole). They also understand the interaction of various elements of the information stream (hardware and software), the complexity of which can often require more than one IT associate to fully understand. Finally, when their skills are cultivated, IT professionals have a firm understanding of how changes within an information system impact the value stream and affect employees, customers, and suppliers.

The “geek nerd” is nothing more than a stereotype. The IT associates I work with in many diverse organizations including finance, logistics, healthcare and software, are well read, educated, thoughtful people. A key tenant in Lean is “respect for people.” We often mistakenly understand this to mean that employees are encouraged, treated fairly, given clear goals, and held to accountable for results. Actually, that’s not it at all. In Lean, respect for people is all about coaching people by challenging employees to solve problems; asking for deeper thinking, more data and facts, and more dialogue. This is experienced as uncomfortable and difficult work when employees (particularly in IT) just want to implement a solution!

IT associates are more than capable of responding to this kind of challenging work. They possess the aptitude for deep analysis and reflection that is required to make significant Lean improvements. All that is needed is a willingness to try. The first step is to make the time to involve IT in Lean activities. Lean IT is an untapped goldmine just waiting to be unearthed!

Who Is Responsible for Quality?

This week we’re going to take a break from talking about Agile in IT operations so we can examine quality in IT.

When Edward Deming, the Grandfather of Quality, taught his methods to the Japanese in the 1950's, he was working with a group that had historically been known for poor quality. Invited by the Japanese Union of Scientists and Engineers to assist Japan in their post-war reconstruction efforts, Deming taught Japanese management, scholars and engineers to focus on quality in order to produce world-class results and become competitive in world markets.

Japanese Leadership

During his early lectures, Deming quickly realized that quality cannot be sustained unless an organization’s leadership focuses on its importance. Initially, he lectured plant managers and engineers who had no authority to implement change. When Deming consulted with his Japanese hosts, they understood the problem and arranged for him to speak to about 100 top-level business leaders.

Deming instilled in these leaders a sense of responsibility for quality in their organizations. He maintained that, ultimately, quality is created in the boardroom and is the responsibility of top management. With senior management supporting quality efforts, the Japanese companies and economy would flourish.

Japanese Success

Deming predicted that Japanese companies would export their products all over the world and companies in other countries would be clamoring for trade protection from the Japanese within five years if they followed his recommendations for improving quality. Although the Japanese business leaders did not initially share his vision, they did as he instructed so they would not lose face. Japan surprised the world with their success and even beat Deming’s prediction by a year.

You probably know the rest of the story regarding Japan's success and what American organizations had and still have to do to catch up with Japanese firms. American firms confused quantity with quality. Demand for American goods was so high in the 50's and 60's the American manufacturing companies assumed this translated to quality for the customer.

However, this misconception was created from the great economies of scale available to American companies due to the war engine. At the time, the United States was the only country in the world which could produce at levels necessary to meet demand. As soon as Japan could both meet demand and offer higher quality, American companies fell behind in world markets.

Putting Out Fires

I have found that many IT organizations function similarly to the manufacturing model that existed before Deming’s quality movement. They judge the quality of their product, IT services, by the demand for that product.

For example, when a system goes down and IT team members scramble to get it working again, companies reward this behavior by praising the heroes who got up in the middle of the night to fix the issue. These individuals are suddenly visible and valuable. They are motivated to continue putting out fires rather than to improve system stability. The incentive to become system arsonists is greater than the motivation to create quality systems.

Continuous improvement is a hard sell for some IT professionals because doing a quality job means nobody notices IT. The better the systems run, the fewer chances there are for heroics. A quality IT group is almost invisible.

Deming’s 14 Points

Below are Deming’s 14 points for management transformation. They were originally published in Out of the Crisis by W. Edwards Deming.

Although the 14 points were written for a manufacturing scenario, try to translate the recommendations into ideas for an IT team. Following these points in your IT group can help you focus on making quality everyone's responsibility.

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.

6. Institute training on the job.

7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company.

9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.

b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.

11. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

12. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means abolishment of the annual or merit rating and of management by objective.

13. Institute a vigorous program of education and self-improvement.

14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.

Deming’s 14 points transformed manufacturing into a quality-focused delivery system. The same benefits can be realized in IT, creating continuous improvement in IT processes and products. When quality is built into your IT systems you can increase the value of your department to the business, decrease time spent on downtime and reduce the load on team members who have to fix problems caused by a lack of quality.

The Journey Toward Quality

I realize I am not giving much in the way of suggestions for translating the 14 points into action but I would encourage you to study how you can facilitate making quality core to your business.

All the excuses you will hear from your team about why these 14 points won’t work in IT are probably the same excuses manufacturers made before they made the shift to quality. The arguments have already been made and overcome and the benefits of following the 14 points have been clearly demonstrated.

If you haven’t started the journey toward increased quality and would like help, feel free to reach out to me. I can provide you directions to start. Good luck!

Patrick Phillips and Jen Browne