CMMI Overview v1.3

Faster, Cheaper, Better by Michael Hammer and Lisa Hershman

Faster, Cheaper, Better
The 9 Levers for Transforming How Work Gets Done
by Michael Hammer & Lisa W. Hershman
A Review

A REENGINEERING HOW-TO FOR EXECUTIVES

One of the co-founders of the reengineering movement, Michael Hammer has always focused on how companies get things done more than what they need to do. In Faster, Cheaper, Better: The 9 Levers for Transforming How Work Gets Done, he and co-author Lisa Hershman, CEO of Hammer and Company, offer a detailed framework for improving the key processes in a company — the five to ten end-to-end processes, from product development to order fulfillment, that bring all the value to the company's customer. "End-to-end" are the key words in the authors' approach.

Processes in most companies are fragmented: different people or departments doing different tasks along the process with no real thought given to the efficiency of the entire process. "Most people want to do a good job," write Hammer and Hershman. "They are given goals and they strive to meet them. They focus intently on doing their job correctly and well, and they are rewarded for their efforts. But few understand how their narrowly defined jobs fit into the overall picture of what the company is trying to accomplish."

Value for the customer is not created by a job, it is created by a series of jobs that together form the end-to-end process, the authors argue. This focus on end-to-end processes may remind readers of Hammer's classic reengineering approach in Reengineering the Corporation and with good reason. That book, the authors write, explained why the end-to-end process was the better way to organize the operations of a company. Faster, Cheaper, Better explains how to "harness" the concept to make the company more profitable.

Using the Nine Levers There are, according to the authors, nine levers that companies can use to improve the performance of their end-to-end processes. The first five involve the design and execution of the processes. The authors call these levers "process enablers."

The five process enablers identified by the authors are:

The process design.
Companies need to design new end-to-end processes focused on the needs of their customers and eliminate redundancy in the processes.

Metrics.
Instead of letting each function select its own measures, use customer-focused process measures.

Process owners.
Designate formal process owners — with the responsibility and the authority to improve the entire process — to work with the traditional functional leaders.

Performers.
Redesigning processes changes the way people work. Performers must see their job as part of the whole value-creating process.

Infrastructure.
A new approach to work by the performers requires a new infrastructure to support them — including new compensation plans, new training and development opportunities, a new reporting structure and the necessary tools.

Through their experience with numerous companies, the authors found that implementing these five process enablers could only succeed if four enterprise capabilities were in place:

Leadership.
The leadership of the company needs to think in process terms, not functional terms, and to align their efforts to improve end-to-end processes.

Culture.
The best companies will have a process-based culture that is relentlessly focused on the customer.

Expertise.
Process management and redesign need to be core competencies within the organization.

Governance.
A formal governing infrastructure needs to be in place to implement end-to-end processes, such as a program management office that includes a chief process officer or a process council at the top of the organization.

Faster, Cheaper, Better combines a detailed, extensively researched, yet practical methodology with continuous examples of the methodology's application to the real world — both within the discussion of the methodology and in the second part of the book that offers in-depth case studies. A summary chart at the end of the book, that shows the nine levers in four different stages of maturation, provides yet another guide for companies to improve their processes. This is a business book that delivers on its promise to transform how works gets done in your company.

Why Agile isn't working

Why Agile Isn't Working: Bringing Common Sense to Agile Principles

Agile promises many things, but the reality in the field is often very far from the expectations. Is it agile we need--or an agile way of thinking?

By Lajos Moczar
June 4, 2013

 

Changing Agile Thinking With 3 Common Sense Principles
One thing that's seductive about agile is the name. We like the idea of being agile in our thinking. Agile as a methodology cannot deliver agile thinking, however, and inevitably ends up preventing it.

Think of "agile" as the ability to take the input of all the variable elements of the project—budget, time, design patterns, reusability, customer needs, corporate needs, precedents, standards, technology innovations and limitations—and come up with a pragmatic approach that solves the problem at hand in such a way that the product is delivered properly.

This sounds like a tall order, but really comes down to three common sense principles. If there's one key quality a good project manager needs, it's prioritization: The ability to take the pressures of all project elements and determine which path to follow based on what's most important to achieve.

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It's the role of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

One of the hardest things for many developers is pragmatism. Rather than think practically, they inevitable fall into abstract approaches to problems. I was on one very expensive project based on a purist design in which everything was reusable and could be dynamically coupled together. It was a marvel of abstraction. The only problem was that it didn't work. It had the worst performance I have ever seen in a Java system and was incapable of supporting the required load. The core problem there was that the team attempted to solve real-world problems with an abstract approach.

No matter how virtual technology gets, it's still ultimately based on the physical world that we humans operate in. Physical problems cannot be solved abstractly. Look at any factory machine and see how many oddly shaped parts it contains, each good for just one very vital physical function. Software is no different. Sometimes things are meant for one use only. That's not a bad thing if it gets the job done and functions properly for many years.

Finally, dynamism means the ability to switch strategies when the current one isn't working. Many times, despite our best planning, what seems like a good project, design or development strategy hits a brick wall. The most important thing in this situation is to know when to call it off. If the brick wall is only a brick wall, a bit of brute force—i.e. one or two late nights—will get through it. But if it's really a mountain of rock, it's best not to risk the entire project but, instead, find another way around.
It sounds like a simple concept, but I've watched projects go on for weeks, team members beating their collective heads against the mountain, only to conclude too late that another approach was needed.

Agile promises solutions it cannot deliver. It promotes sloppy requirements, hides the true cost of development and prevents effective management. Contrary to what we're told to expect, this leads to long-running projects, dissatisfied customers and an overall IT ineffectiveness. What we hope to find in the methodology, however, is achievable through agile thinking. With this thinking, we can in fact solve the problems of IT project management and learn how to deliver stable products on time and to budget. If the project team knows how to think and work effectively, then we don't need to look to a methodology to save us from project failures. We can do it ourselves.

Retrieved from
http://www.cio.com/article/734338/Why_Agile_Isn_t_Working_Bringing_Common_Sense_to_Agile_Principles

Lajos Moczar is a senior technology strategist and consultant, operating as The Consultant CTO. When not consulting, he writes on various IT topics. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.

Using a blog as a collaboration device for virtual teams

According to Tim O'Reilly, Web 2.0 can be thought of as "a set of principles and practices" that underlie a new conceptualization and usability of the Web, born out of the dot.com crash in 2001.  Although the term itself has been widely used, (and misused) its core features persist.  Some of the key features of Web 2.0 are the concept of the Web as a platform, with an architecture of participation, in which the users control their own data, but allows for endless remixing so as to harness the power of collective intelligence. 

O'Reilly noted that "hyperlinking is the foundation of the web" and pointed to the rise of blogging as one of the central features of Web 2.0.  Blogs are personal weblogs or online diaries that are predominantly a chronologically ordered set of text-based entries.  Gradually, the inclusion of imbedded images, audio and video made the blogging experience more multimedia.  There are two critical features of a blog that make it different from an online forum discussion board or a wiki.  The first is tagging, and the second is permalinking.  These two features (discussed in more detail below) gave me the idea of using a blog as a collocation conversation management device for virtual teams.

First, what do I mean by virtual teams?  "In today’s business environment, project teams comprise highly specialized members, many of whom may not be collocated. Thus, rather than forming traditional teams, virtual teams, comprised of members from different geographic areas, are assembled to collaborate on a project. Virtual teams are commonly used for tasks such as developing systems and software; for example, the programmers are located in India, the project managers are in the United States, and the testers are in Europe." (Valacich and Schneider, 2012).

In a sense we are all involved in a large-scale virtual team through the mechanism of Blackboard which is facilitating our distance learning and collaboration in this class.  I am involved with such a virtual team in another class that is working on a large-scale business process modeling case.  In thinking about how best to organize our efforts and keep track of our communication, noting that some of us are in different time zones, I considered using a blog.  In part this is due to that fact that I am familiar with blogs and have been using them off and on since 2003, and that there are numerous free platforms online to support blogging.  (I personally use blogger.com).

The two features that O'Reilly mentioned (tagging and permalinking) make blogs an especially versatile and useful tool for this kind of collaborative work.  Although Blackboard's discussion forum does allow for the creation of different discussion threads and stimulates the back and forth of online conversation, it is limited to a hierarchical, nested structure.  Individual posts have a fixed location in the existing structure, but it is not possible to tag particular posts or to do searches of all posts across multiple conversations. 

What do I mean by tagging?  Tagging is a simple, yet powerful means of establishing an emergent structure out of multiple conversation threads and discussion topics, on the fly.  Some refer to this as "folksonomy" as opposed to taxonomy.  Taxonomy refers to a systematic classification into ordered, predefined categories, like that found in any encyclopedia.  Folksonomy refers to "a style of collaborative categorization of sites using freely chosen keywords," ie. tags.  Tags can be applied by the author of a post at the time of posting, but the real benefit is that the possibility of tagging can be opened up to the readers of a post as well.  This feature is sometimes called "social cataloging."  "Tagging allows for the kind of multiple, overlapping associations that the brain itself uses, rather than rigid categories." (O'Reilly, 2005).  Blogs offer the additional functionality of allowing searches and reordering or filtering of posts by tags, something a discussion board cannot do.  Another feature is the tag cloud, (see example) which is a way to "visualize user generated tags or content on a site ...The size of a word in a tag cloud represents its importance or frequency so that it is easy to spot the most important or frequent words or tags." (Valacich and Schneider, 2012, 207).  Out of a tag cloud comes an emergent dynamic structuring of the posts.

Permalinking is the second feature of blogs that make them a good tool for virtual team collaboration.  Permalinking a blog post gives it an easy handle, a way of referring to any specific part of a conversation utilizing the power of hyperlinks, making it "relatively easy to gesture directly at a highly specific post on someone else's site and talk about it."  This is extremely useful for teams with multiple participants who are geographically and temporally dispersed.  Without having to search throughout the discussion board to see which threads have new "unread" posts, I can dynamically follow the asynchronous updates from multiple team members and easily refer to the embedded permalinks to refresh my recollection of the previous step in the conversation.  Each blog post can also have a nested set of comments appended to it, tracking the flow of a discussion with multiple participants.

The combination of tagging and permalinking means that a blog can replicate the functionality of either a wiki or a discussion board.  Tags create a user defined folksonomy and allow one to search or reorder posts based on that new classification schema.  Permalinks let us pin important posts which define terms, establish procedures, set goals, identify measures or outputs as permanent, but changeable, fixtures in our emerging dynamic structure. 

I am assuming, of course, that all of the virtual team members are empowered as administrators or authors of a team blog.  Each participant can make his or her own posts, edit others postings, suggest edits or changes, make comments on other peoples posts, and set tags on her own or on others posts.  Blogging creates a record of the process that the team is going through, it can be reviewed as a set of minutes of the meetings that the team has had, as well as a record of the evolution of a draft proposal or a process redesign.  It provides not only a historical document but also, if used properly, a dynamic conversation management device.  An important benefit is that unlike discussion boards, blogs usually feature a mobile app or email interface which allows one to easily publish to the blog through an email.  Like any tool, it can be misused.  One of the drawbacks to blogs is that readers with no special privileges can only make comments.  To them it may only seem like a static chronological list.  Another serious consideration, brought up by Valacich and Schneider, is "the damage that can be done to the company when a poor choice of words, an unpopular stance, or a rogue employee’s rant is posted in a blog."  But overall, I believe the benefits outweigh the costs and that team blogs can be a valuable means of managing the collaborative work of dispersed virtual teams.     

Works Cited

O'Reilly, T. "What is Web 2.0?"  oreilly.com.  (September 30, 2005).

Valacich, J. & Schneider, C. (2012). Information Systems Today, Managing in the Digital World.

Upper Saddle River, New Jersey: Prentice Hall.

Take a tour at www.blogger.com

What are process metrics?

As Harmon says one of the key steps in developing a business process architecture is to "determine how you will measure whether or not the value chain achieves its goals."  This is a point that is reiterated by Cooper and Patterson; "Success with BPM is almost always measured with a clear simple business metric … If you can't identify a metric that is meaningful to your business partners, you need to step back and evaluate if you have identified the right target process.”  (Cooper and Patterson, 2007).  Measurement is closely related to the steps of identifying a specific value chain and determining the specific strategic goals that the value chain is to achieve. 

Harmon indicates that there are two types of measures of business processes; internal and external.  The external measures focus on the results achieved by the value chain that the process is a part of and relate to the ultimate customer of the value chain.  Internal measures are focused inward on the process itself and relate to the efficiency of the process.  "External measures let us know how well the process is doing what it is intended to do. Internal measures let us know how effective the process is in producing outputs. Put slightly differently, External measures check results and Internal measures check productivity."

One similarity is that both internal and external measures can be thought of as relating the activity of the process to its customer, if one wants to consider any process that receives another processes' outputs as its customer.  In that sense a process is both "a supplier of one process and a customer of another."  Looking at metrics related to the output of a process and the customer satisfaction with that output is what binds both internal and external metrics together. 

One key difference between internal and external metrics, is that internal measures are leading indicators and are easy for managers to identify, collect and interpret.  External measures are often harder to identify and obtain in concrete quantifiable measures.  Measures like customer satisfaction also tend to be lagging indicators and knowing about them only comes after the performance of the process.  However, Harmon points out that although they should be used in conjunction, "to effectively evaluate the performance of an organization, you must focus on the external measures.  Once you "lock down" the external measures, then you can begin to focus on improving your internal measures."

Works cited

Cooper, M., Patterson, P. (April, 2007). Business Process Management (BPM) Definition and Solutions. http://www.cio.com/article/106609/Business_Process_Management_BPM_Definition_and_Solutions (Accessed on September 18,2012).

Harmon, P. (2007). Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals. Burlington, MA 01803: Morgan Kauffman Publishers.

Harmon, P.  Measurement and Services. (May 13, 2008).  BPTrends. (6:9).
http://www.bptrends.com/publicationfiles/advisor20080513.pdf (Accessed on October 3, 2012).

What is Enterprise Architecture? What is Zachman's Framework?

Briefly describe the Zachman's Enterprise Architecture framework. Describe 1-2 of its strengths.

1.0   Enterprise Architecture Defined
According to Gartner.com, (http://www.gartner.com/it-glossary/enterprise-architecture-ea/) an Enterprise Architecture is defined as:

“the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.”

Capgemini defines Enterprise Architecture as:

“a set of principles, rules, standards, and guidelines, expressing and visualizing a vision and implementing concepts, containing a mixture of style, engineering, and construction principles.”

The Open Group’s Architectural Framework (TOGAF) notes that:

“[Enterprise] Architecture has two meanings depending upon its contextual usage: (1) A formal description of a system, or a detailed plan of the system at component level to guide its implementation; (2) The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.”

US Federal Enterprise Architecture Framework (FEAF) definition:

“Enterprise architecture is a management practice to maximize the contribution of an agency’s resources, IT investments, and system development activities to achieve its performance goals. Architecture describes clear relationships from strategic goals and objectives through investments to measurable performance improvements for the entire enterprise or a portion (or segment) of the enterprise”

2.0   Enterprise Architecture Framework

An Enterprise Architecture is an extremely complex and complicated systems model.  Because of its size and complexity, EA frameworks or methodologies have been developed that provide a set of tools, techniques and terms to bring the EA into focus.

According to Sessions (2007):

“Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy

The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process

The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture

The Gartner Methodology—Can be best described as an enterprise architectural practice

3.0   Zachman’s Framework

“The field of enterprise architecture [methodologies] essentially started in 1987, with the publication in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman.  In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years.  The challenge was to manage the complexity of increasingly distributed systems.  As Zachman said:

The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. [02]

Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise architecture framework.”

Zachman’s framework “summarizes a collection of perspectives” and is a “logical structure for classifying and organizing descriptive representations.”  It is depicted as a grid or matrix of six rows and six columns.  “Zachman proposed that there are six descriptive foci (data, function, network, people, time, and motivation) and six player perspectives (planner, owner, designer, builder, subcontractor, and enterprise.) These two dimensions can be arranged in a grid…There are 36 intersecting cells in a Zachman grid—one for each meeting point between a player's perspective (for example, business owner) and a descriptive focus (for example, data.)”

4.0   Strengths of Zachman’s framework

One of the strengths of this framework is that “it explicitly shows a comprehensive set of views that can be addressed by enterprise architecture.”
Another strength of this framework is that it provides for a very high level of detail in the artifacts created or depicted.

Because of the relatively large number of perspectives engendered in the framework, it provides a very narrow focus on each of the Enterprise Architecture components.

WORKS CITED

Op’t Land, M.; Proper, E.; Waage, M.; Cloo, J.; Steghuis, C. (2009). Enterprise Architecture: Creating Value by Informed Governance. Springer. (http://www.springerlink.com/content/978-3-540-85231-5) (Retrieved September 17, 2012).

Sessions, R. (May 2007). A Comparison of the Top Four Enterprise-Architecture Methodologies.  http://msdn.microsoft.com/en-us/library/bb466232 (Retrieved September 12, 2012).

Zachman, J.A. "A Framework for Information Systems Architecture." IBM Systems Journal, Volume 26, Number 3, (1987).