Saying 'Yes' And Saying 'No'

'Yes' and 'No' are the two most important words in any business. Those two syllables, by themselves, determine whether there business will be done and whether a sale will be made. They determine whether a customer will be satisfied. I do not exaggerate when I say companies rise and fall by their use of 'Yes' and 'No'.

As people, we are defined by that to which we say 'Yes' and that to which we say 'No.' Whatever else we say, these two words set forth our values, establish our priorities, and define our boundaries. The same is true for any business--'Yes' and 'No' give a business its form, its culture, its style.

Is either one more important than the other? No. Saying 'No' to a bad idea or a bad proposition is just as much a positive outcome as is saying 'Yes' to a good idea or a good proposition. The particular word, 'Yes' or 'No', matters far less than the substance to which one says 'Yes' or 'No'.

At Voice The Right Way, we say 'Yes' to good business wherever it may be found. We say 'Yes' to keeping our customers satisfied, and meeting their needs as much as we can. Naturally, "good business" for us necessarily entails profit--we can and we will say 'No' to business proposals which are not reasonably certain of turning a profit--but if a customer need or a customer want can be both adequately served and profitable then we will always say 'Yes' to serving that need or want.

Our saying 'Yes' to our customers directly influences how our network is built out, and how our systems are designed. 

• We say 'Yes' to customers being able to use their own VoIP devices and softphone clients, so while there is a preferred list of devices that we will automatically provision, we also provide instructions for manually configuring any device not on our supported list. 
• We say 'Yes' to our customers being able to grow their businesses without losing economies of scale, and so we have devised enterprise pricing plans that allow our customers to purchase exactly the resources they need for as long as they need. 
• We say 'Yes' to our customers being able to use VoIP as a vital tool for their businesses, and so we constantly strive to improve our own systems and enhance the value they deliver, both in terms of service quality and an ever expanding list of features.

By the same token our saying 'No' impacts how we do business.

• We say 'No' to a constant stream of "small" charges and fees; we strive to make our invoicing simple, transparent, and straightforward. 
• We say 'No' to extravagant but empty promises that surpass what our systems can offer; rather, we focus on listening to our customers and crafting solutions that actually meet their specific needs, and not some sales-driven vision of what they "should" need. 
• We say 'No' to "vaporware"--solutions, capabilities, and infrastructure that we have not yet built or acquired; we strive to be straightforward and transparent with our customers, no matter the circumstance.

Every business claims to be focused on serving their customers. At Voice The Right Way, we demonstrate that focus with two simple words: 'Yes' and 'No'.

The Action Plan: Project Management Made Simple

"Luck is what happens when Preparation Meets Opportunity"

Seneca

There is rarely a year where at least one study is not published bemoaning the high levels of project failure within the profession of Information Technology. In 2009, a study by IAG Consulting found that 68% of IT projects were unlikely to succeed, and when they did succeed it was largely attributed to pure luck. In 2012, a study by McKinsey and Company, in conjunction with the University of Oxford, found similar results:

On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns

A frequently cited cause of project failures, cost overruns, and missed deadlines is a lack of communication or a lack of effective communication--a perverse irony given that IT exists as a profession in part to facilitate communications. Even causes such as "poor planning" and "lack of leadership" are ultimately attributable to poor communications.

As poor communications is a cause of project failure, improving communications during various project phases should improve the probabilities of project success. Having had the privilege of leading a variety of technical teams over the course of my career, I have learned--occasionally the hard way--the particular importance of effective communications in accomplishing virtually any goal or objective imaginable.

One profession where effective communications is literally a matter of life or death is the military: throughout history, battles have been either won or lost on the quality of communications between various military units.  The United States Army and Marine Corps address this challenge through the use of the Operations Order, also known as the Five Paragraph Order. The purpose behind the Operations Order format is clear and concise communications which can be transmitted and received in the very chaotic conditions of the battlefield. An ancillary objective is eliminating potentials for miscommunications or misunderstanding.

An IT project is not a matter of life or death, yet there is still a pressing need for clear and concise communications. With the interactions among multiple technical specialties that take place within most IT projects, the parallels to military operations can easily become a rather expansive list. Consequently, it is not unreasonable to look to military communications as a guide for improving project communications within IT. With that in mind, one can adapt the military Operations Order format for IT projects. I call my adaptation of this format the Action Plan.

The five paragraphs of the military Operations Order--and thus of the Action Plan--are as follows: Situation, Mission, Execution, Administration/Logistics, Command/Signal (I typically title this section Communications). The extent to which one wishes to follow the military structure will vary, but I have rarely seen a need to replicate more than this top-level structure; analogies by their very nature are imperfect relationships, and it would be ill-advised to expropriate a communications structure designed for moving tanks and artillery to use for moving servers, switches, and routers unmodified. However, I have found that this basic structure lays out a comprehensive communications format that allows everyone engaged on a project to understand what is taking place.

Situation

The Situation paragraph is the task's background and context. Here one would describe the particular business problems that need to be addressed, as well as any technological priorities that might exist. The need to address a severe zero-day exploit would be one example of what would go into the Situation paragraph. Alternatively, the rationale for moving a data center or other operational facility would be placed here. 

Mission

The Mission paragraph should be a clear and concise statement of task objectives. Depending on the task, it might even be a single sentence--and I have found that using fewer sentences here is better. "Apply firmware updates to all network routers" would be one example of what would go here. "Install replacement servers/switches/access-points" would be another example. If it is an object of the exercise, it needs to be stated in this Mission paragraph. 

Execution

The Execution paragraph is not really a paragraph at all, but rather a specific task list. The task list might be broken down by individual or individual area of responsibility, or all relevant actions might be contained within a single task list--adapt as needed to fit the realities of the project. The crucial characteristics here are that the tasks specific--right down to the individual server and/or software revision number--and are sequential--the tasks that need to be performed first should be listed first. 

While the Execution paragraph needs to be comprehensive, as with all the parts of an Action Plan it needs to be brief. Thus, in large or highly complex projects, the tasks within an Action Plan might themselves lead to subordinate Action Plan documents. The Execution paragraph of a global Action Plan for a project might describe the specific task objectives for a number of different technical teams, and in turn each of those teams would devise their own Action Plans to address the particular requirements of their specific task objectives. 

Administration and Logistics

The Administration and Logistics paragraph is where any special resources or equipment items get mentioned. Similarly, an outside vendor either on hand or standing by in case of an unforeseen even would be listed here. If there are special contingency considerations, this is the paragraph where those get documented. Whom gets tasked with deciding whether to abort a task also gets listed here.

Communications

The Communications paragraph outlines how members of the assigned team can communicate with each other. Responsibilities for providing communications beyond the project team are also detailed in this paragraph. 

The goal of the Action Plan is to inject certainty into project management by giving a concise and comprehensive description of what is in. Properly written, the Action Plan clearly sets expectations, identifies objectives, and describes every person's role within the overall project. To the greatest extent possible, it seeks to remove thinking from task execution; thinking and planning ideally take place before task execution, not during. By unburdening team members in this fashion, they are able to be more adaptive and flexible during the execution phase of a project, simply by virtue of starting the project knowing their individual objectives.

There is a psychological benefit to the Action Plan as well. In its structure, its tone, and hopefully its verbiage, it is goal oriented rather than process oriented. It focuses attention on project goals and objectives, with only secondary emphasis on project process--the "what" is far more important within an Action Plan than the "how". This emphasis allows project leadership to focus on managing results and outcomes while simultaneously allowing all project participants to bring their various skills and experiences to bear on determining methods and processes to be used. 

Most importantly, the Action Plan aids in the planning process itself. Even before an Action Plan is written, applying a standard communications framework to planning discussions allows effective plans to be built. The Action Plan is as much about the process as it is about the documentation. Whether a team employs top-down leadership or uses a more collaborative structure, the Action Plan approach brings systematic organization to planning efforts. It is a comprehensive structure, able to address all portions of a project, and yet it is simple enough to be easily reproducible throughout a project, enhancing organization and coordination at all levels.  As a planning activity even for individual work, I have found that using this format as a guide makes individual efforts more effective simply by bring a measure of order to activities; by working through the steps of a particular project or task in this structured fashion before undertaking them, potential flaws or missed steps can be identified--errors and failures can be pre-empted and avoided, and every problem avoided is a problem one does not have to devote scarce time and effort to solving.

No document is ever a substitute for actual planning, and even the Action Plan structure is undermined if one merely works through the document by rote, treating it as merely an item to be checked off.  An Action Plan is a guide, not a mandate. However, when used as a guide, it will simplify project planning, and enhance project communications. It will facilitate the full engagement in a project by project team members, ensuring a maximum contribution by each member towards project success.

Good project plans increase the chances for project success. If luck is the convergence of preparation and opportunity, the Action Plan is one preparation that gives all project participants the opportunity to get lucky and succeed.

Success Is Always By Design

Success, be it in a project or any other human endeavor, never happens spontaneously. It is the result, not merely of effort, but also of deliberation, of thought--i.e., of design. Success is never an accident--the better the design the greater the success, and, similarly, the weaker design the less likelihood there is for success.

Giving thought to what constitutes quality design is a fair summation of the discipline of engineering.  The close connection between each of the terms, as well as the concepts, is easily intuited by consulting any dictionary (my personal preference is Merriam-Webster) and noting that "engineering" is defined in terms of "design": "the work of designing and creating large structures (such as roads and bridges) or new products or systems by using scientific methods." Although we habitually use the term "engineering" in relation to large construction projects, within the basic definition one can easily see how engineering concepts can be brought to bear in almost any field of human endeavor.  "Engineering", to my mind, is the science of design.

Understanding any science begins with an understanding of its first principles. To understand, then, the science of good design we must first examine the principles and the process of design itself--for there is a logical conceptual process that informs all design efforts (and the quality of our design hinges on the extent to which we leverage that process).

An excellent depiction of the design process comes to us courtesy of the Massachusetts Institute of Technology's Open CourseWare initiative, which makes a variety of classroom lectures and supporting materials freely available online.  In particular, I make reference here to the 10-step design process outlined in ESD.051J Engineering Innovation and Design.  As presented in that lecture series, the ten steps in the fundamental design process are as follows:

Identify Needs

What problem are we attempting to solve? What are our goals and objectives?

Information Phase

Do any solutions for the problem already exist?  What are they? What are their strengths and weaknesses?

Stakeholder Phase

Who desires which specific goal or objective? Why?

Planning/Operational Research

What's realistic? What limits us?

Hazard Analyses

What's safe? What can go wrong?

Specifications

What's required? How do we define success?

Creative Design

Ideation

Conceptual Design

Potential solutions

Prototype Design

Create a version of the preferred design

Verification

Does it work? If not, redesign

Note: I do not intend an in-depth exploration of these phases here. I highly recommend visiting the MIT Open Courseware site for a more thorough presentation of this process.

What is noteworthy about this process is that it is not tied to any particular technological or scientific paradigm.  Indeed, it is not tied to any particular discipline at all.  One could apply this process not only to the development of industrial products and technologies, but also to project plans, marketing plans, and even the creation of art (this is not as far-fetched as it might seem--several of the world's foremost industrial designers, such as Dieter Rams and Apple's Chief Design Officer Sir Jonathan Ive began their studies within the world of art, and Dieter Rams' designs have been gathered into a traveling exhibit Less and More, which has been displayed at art museums around the world).

This process works because it is comprehensive. It demands that one reach outside of his or her own thoughts and ideas, and specifically engage with others, solicit input and ultimately feedback from others. Throughout, the design process explicitly seeks connection to the reality surrounding the effort, and, in an iterative fashion, requires constant validation of effort against that reality.

With so much attention devoted to design, why do I speak of engineering in the title of this posting? The answer is simply this: Conceptual consideration of a design process, or of any process, itself yields no tangible results.  That conceptual consideration must be given form and function through practical usage. That practical usage is the discipline of engineering.

In 2012, Dr. Benoit Hardy-Vallee, writing for the Gallup organization, reported on a study published in the Harvard Business Journal that found, out of 1,471 IT projects, average cost overruns of 27%, with one in six projects having cost overruns of over 200% and schedule overruns of almost 70%.  Dr. Hardy-Vallee categorized project failure causes into three broad categories:

• technical (technology developed, project management techniques)
• individual (project leadership, scope management, communication)
• stakeholder (user involvement, executive buy-in, goal specificity)

Dr. Hardy-Vallee concluded that project management failure was largely a result of inadequate "emotional" content. His assertion was that project management current literature was rich on process controls and methodologies, but severely lacking in ways to engage various project stakeholders at an emotive and psychological level:

The problem with a single-minded focus on processes and methodologies is that once people are given procedures to follow, compliance replaces results. Everybody is concerned about how to do the job, not about the outcome if the job is done well.

However, when one considers Dr.  Hardy-Vallee's causes of failure against the backdrop of the fundamental process of engineering design outlined above, one can match the causes of failure to particular phases of the design process (and sometimes to more than one phase of the design process), and so a different conclusion becomes possible--that projects fail from poor design and from poor implementation of a design. Projects fail because of a lack of good engineering. 

In an engineering paradigm, processes that do not produce good results are not good processes; they should be altered and adapted until they do produce good results. Likewise, methodologies that do not yield successful outcomes are not successful methodologies, and should be revised so that successful outcomes are obtained. Because of the iterative nature of the design process, "compliance" in the engineering paradigm becomes the pathway to results, and thus is the complement to those results and never its substitute. (The "engineering" response to Dr. Hardy-Vallee's emphasis on a need for "emotional" content within project management would be that by definition, effective stakeholder analysis phase of design engages all project participants at that emotive and psychological level).

Behind every victory is a good plan. Behind every triumph lies preparation, forethought, and deliberation. Behind every success is a good design.