The 16 Rules of DMAIC

07/31/2022:

This multi-part article is the fourth in a series of five serialized parts that explores why all businesses, all

organizations, and all enterprises should consider daily standups as an integral part of their overall

project and operational communication planning.

Despite the adoption of the Agile framework globally, having a daily standup seems to have been thrown

to the side as a waste of everyone’s time. This article asserts the contrary, that maintaining a disciplined

daily standup regimen is absolutely necessary from a communication and conflict resolution perspective.

It explores eleven common reasons why projects - and by extension, daily operations - fail, and how daily

stand-ups are a necessary first step to achieving overall outcome success.

Go to Previous Part 3

Eleven Good Reasons for Daily Standups - Part 4

Project and Operational Failure (continued)

Lack of executive support is pretty hard to understand. Why would a member of the executive or a

senior manager agree to fund and provide resources to a project, and then fail to support it?

It is important to keep in mind the rhetorical question: who is most likely to complain about the lack of

executive support? All would agree that it is not the executives complaining about themselves; it is a

subordinate complaining about their supervisor. Perhaps that complaint is justified, and perhaps it is not.

There is a popular -- and admittedly seductive -- parable popularized by the publication of the Peter

Principle (Peter and Hull) in 1986), that individuals working in hierarchies tend to continue to rise in the

organization until they reach their level of incompetence.

With all due respect to Occam’s Razor, this is a simplistic explanation for a very complex and dynamic

“science of management” problem. It presumes that all organizations -- regardless of size, organizational

structure, corporate culture, ever-changing group dynamics, and circumstances -- operate in exactly the

same way, every single time. We know this assumption to be untrue, else all successful CEOs who have

been lured away from their parent company to lead another would always succeed in their new role.

But one thing that we do know about hierarchies is that the higher you go, the more meetings you are

expected to attend. Another thing we know -- and as noted by Porter and Baker (2006), despite mutual

finger-pointing and “I’m not the problem” protestations -- most meetings are not run well.

While it is admittedly anecdotal, my own experiences as a consultant and contractor support this

conclusion, despite my own efforts to suggest changes in this most important business activity.

Overly complex communication plans are as bad as no communication plan at all. Moreover, most

businesses have no formal practices surrounding the responsibilities of executive project sponsorship.

Unsurprisingly, there is no Standard Operating Procedure for the role and responsibilities of the Project

Sponsor. In many instances, the role does not even exist.

The Sponsor’s role is essentially to be an effective link between the executive level and the project team

and to manage the expectations of the project stakeholders. While their role does not include attending

regular project meetings, and certainly not micromanaging the project team, it does not imply taking a

hands-off approach to the project or its frontline workers.

Though not a formal role responsibility, an attentive Project Sponsor should take the time to informally

collect qualitative team data using the practice of, “Managing by Wandering Around” (MBWA). It is also

referred to as “Walking the Halls”, or what I prefer to call, “The Manager’s Walkabout” (MCL &

Associates, 2022). This is an important management technique that has, unfortunately, fallen out of favor

long before geographically dispersed teams and virtual meetings became an everyday reality.

At its heart, leadership is about the development of accurate communication and trust. Many executives

and managers could greatly benefit from developing better leadership skills to support their

management responsibilities.

Changing Requirements and Specifications are a given for any project. The goal for all project

management frameworks is to minimize the amount of work expended on requirement and specification

changes and still deliver an end product, on time and on budget, that is fit for purpose. What makes Agile

unique from Waterfall is that change is assumed; the customer may have a very clear idea of what they

want, but a very unclear notion of what will be required to get there, or how much time and resources it

will require to get there.

Requirements and specifications can change for any number of reasons: 1). a requirement, or a set of

requirements, get overlooked; 2). a shift in market or customer demand occurs; 3). organizational policy

changes or internal politics; 4). Changes in Laws and regulations; and 5). identification of bugs or

defects.

There are things that are realistically within the scope of management control and there are things that

are not. When everything is said and done, the issue comes down to early detection and prioritization of

tasks and issue focus.

As already addressed, overlooking requirements can be mitigated by including all relevant stakeholders

to the table. While leadership may not be in a position to influence either customer demand, or a change

in laws and regulations, they can certainly anticipate such changes through risk mitigation strategies and

processes. Organizational policy changes and internal political conflicts can be dealt with through a

variety of conflict resolution and informal facilitation efforts. Bug defects can be mitigated by better

quality assurance and customer service processes.

All require effective and efficient internal communication pathways.

Lack of planning, or to rephrase it, the abundance of poor planning -- like every other challenge to

project success -- is a symptom of hidden underlying conditions.

Somehow the Agile approach has been elevated to yet another panacea that will solve all management

production and project management problems, much as all the other IT “flavor-of-the-month” cure-alls that

proceeded it. The Agile admonition that working software -- i.e., working on the software problem at

hand -- should be emphasized over comprehensive documentation has been interpreted as meaning

little or no documentation, including planning.

Without getting into a far-flung debate over how much documentation is enough, the whole point of Agile

is to produce a minimally viable product in the shortest possible time, regardless of whether or not that

effort continues to produce further versions into the future.

This requires planning. And planning always requires communication.

Since most of us are not lucky enough to have been born with eidetic memory, often these planning

details need to be codified in written form for us to refer to. Initial planning details often need to be

reassessed and revised due to changing circumstances and constraints. As a consequence, many of

these artifacts may need to be versioned-controlled as living documents. Moreover, virtually all business

efforts are subject to legal duties of one sort or another. Prudent documentation is always required to

support critical decisions, as well as the various legal and fiduciary responsibilities of management.

The issue is not whether documentation is necessary, but rather how much documentation is absolutely

required to satisfy all appropriate communication needs.

As already noted, frequently the necessary technical and functional resources are not assigned during

the planning phase, but rather after planning has already been completed. Often the scope is either

undefined or over-defined, and therefore realistically unachievable. It is not uncommon for the planning

cycle to be subject to executive micromanaging and excessive reporting.

Communication plans often follow hierarchical top-down and bottom-up patterns, where the flow of

information is as stylized and rigid as Kabuki Theatre.

From a management perspective, there is a downside to implementing the Agile framework approach: it

requires active -- rather than passive -- management participation and leadership. Both product owners

and stakeholders must have daily situational awareness if they hope to support the teams under their

leadership. They must be prepared to manage and lead at the same tempo as their hard-working teams.

No longer are delays to discussing and removing impediments to project and operational bottlenecks to

the next regularly scheduled management meeting acceptable. Problem-solving deferred invariably

results in progress delayed, and frequently exponential problem exacerbation. When such occurrences

are recurrent, or go unresolved - as they frequently do - is it any wonder that so many projects fail, or why

so many operational processes remain profoundly broken?

There are many frameworks to choose from. But none will prove to be adequately efficient or effective

unless management is prepared and able to match the efficiency and effectiveness exhibited by their

teams with efficiency and effectiveness of their own. Both management and leadership require efficient

and effective communications.

Didn’t need it any longer denotes an unambiguous alarm that a project has gone awry in an

extraordinarily significant way. Resources have been marshaled, money has been spent, and

operational plans have been made. And now the product on which all of these efforts have been based is

suddenly no longer needed?

It is the ultimate tacit acknowledgment of, “we quit; we are moving on to some other alternative”.

Often the lowest manager on the totem pole gets the blame. But everyone who has any sense at all about

how organizational decisions are made understands that the Executive-layer has been asleep at the

switch.

Lack of IT management and technical illiteracy fall within a similar category.

As noted by Masli, et al. (September 2016, p. 689): “A fundamental aspect of organization hierarchy

design involves the apportioning of managerial responsibilities between a superior and a

subordinate”.

The paper goes on to point out that splitting or delegating responsibilities without obtaining a superior’s

approval creates three potential risks:

Concerted oversight of a subordinate can be difficult and time-consuming, particularly when

“information asymmetries” are present;

Delegation increases the likelihood of organizational politics and personal relationships skewing the

decision-making process, and;

Where a subordinate perceives a superior to be unfair in some way, it can “negatively shape

subordinate behaviors”.

There will always be information asymmetries. Even individuals who have taken the exact same

professional pathway, who are of the same generation, and have roughly similar belief systems,

inevitably, will view things from a different perspective. If only from the perspective that one is superior in

authority in relation to the other.

The superior wants a specific outcome delivered or accomplished, within a specific period of time. The

subordinate has to figure out how to successfully make that happen.

Even when requirements have been well-documented, communication is required to equalize and fill in

the gaps of task information and executive intent. Predictably, there will be some degree of asymmetry in

technological knowledge. Both the executive and the subordinate need to have a solid grounding in

some area of technology that will allow them to ask the right questions of the other, and of the Subject

Matter Experts (SMEs) and Stakeholders that will necessarily participate.

A worst-case scenario that comes to mind is the National Security Agency’s (NSA) 2001 Trailblazer

Project which “consumed $1.2 Billion of the agency's budget…and it had proved to be a disaster. A fount

of corporate mismanagement, cost overruns, and more to the point...conceptual wrongheadedness”

(2016, p. 156).

Organizational politics and personal relationships are a given because they involve competing roles and

responsibilities, as well as competition over scarce resources and budgets. Frequently these decisions

are “career breaking / career-making” because operational changes are a consequence, along with a

significant commitment of organizational budget and resources. If the project is a success the executive

is a hero; if the project is a failure the executive -- or the individual otherwise held to be accountable -- is

a pariah

If the executive is viewed as acting in an unfair way, subordinates are likely to be hesitant to bring bad

news or present contrary points of view forward. Decision-makers looking for easy technical solutions

that they can manage with ease have an unrealistic view of their role and responsibilities.

Keeping pace with change is absolutely essential for any modern human enterprise.

Where change was once marked by the passage of millenniums and centuries, due to the ever-

increasing pace of technological change, its rapidity can now be measured in scant years, if not months

and weeks. Some applications are changed and updated in hours.

For most of humanity, change is not only personally unavoidable, it is often both personally and socially

disruptive. Each day brings new challenges that must be faced, and new solutions must be found and

implemented. In turn, this triggers the impetus for cultural change: the deliberate effort by some group of

individuals to adjust to external circumstances and challenges impacting their lives.

(Continue to Part 5)

References

agilemanifesto.org_1. (2001, Feb). History: The Agile Manifesto. Retrieved from agilemanifesto.org:

http://agilemanifesto.org/history.html

agilemanifesto.org_2. (2001, Feb). Manifesto for Agile Software Development. Retrieved from

agilemanifesto.org: https://agilemanifesto.org/

Axelrod, A. (2008). Bradley: A Biography. Hounmills, Basingstroke, Hampshire UK: Palgrave MacMillan.

Beck, K. (1999). Extreme Programming Explained: Embrace Change. Reading, MA: Addison Wesley

Longman, Inc.

Burton, J. W. (1969). Conflict & Communication: The Use of Controlled Communication in International

Relations. New York: The Free Press.

Clark, T. R. (2022, Feb 21). Agile Doesn’t Work Without Psychological Safety. Retrieved from Harvard

Business Review: https://hbr.org/2022/02/agile-doesnt-work-without-psychological-safety?ab=hero-subleft-1

Fischer, R., & Ury, W. (1991). Getting to Yes: Negotiating Agreement Without Giving In; Second Edition.

New York, NY: Penguin.

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps:

Building and Scaling High Performing Technology Organizations. Portland, OR: IT Revolution.

Hansson, H. (2020, FEB 14). Purpose of Meetings. Retrieved from dockethq.com:

https://www.dockethq.com/resources/purpose-of-meetings/

Kaplan, F. (2016). Dark Territory: The Secret History of Cyber War. New York, NY: Simon & Schuster.

Masli, A., Richardson, V. J., Weidenmier Watson, M., & Zmud, R. W. (September 2016). Senior Executives’

It Management Responsibilities: Serious It-Related Deficiencies and CEO/CFO Turnover. MIS Quarterly ,

September 2016, Vol. 40, No. 3, 687-708.

MCL & Associates. (2022, 03 17). PEOPLE: What the heck do we do with them? Retrieved from MCL &

Associates, Inc., Small Business Transition Blog: https://www.mcl-associates.com/People-

what_the_heck_do_we_do_with_them.html

Opendoor Technology. (2021, Nov 25). The Standish Group Reports 83.9% of IT Projects Fail - How to

Save Yours. Retrieved from opendoorep.com: https://www.opendoorerp.com/the-standish-group-report-83-

9-of-it-projects-partially-or-completely-fail/

Porter, J., & Baker, E. L. (2006). Meetings, Meetings, and More Meetings. Journal of Public Health

Management and Practice (Vol. 12, No. 1 (January-February), 103 - 106.

Powell, C. L. (2003, Oct 28). Why Leadership Matters in the Department of State. Retrieved from

GovLeaders.org: https://govleaders.org/powell-speech.htm

RingCentral, Inc. (2022, MAR 27). Meet with a Purpose: 5 Types of Meetings. Retrieved from

ringcentral.com: https://www.ringcentral.com/guide-to-better-meetings/types-of-meetings

Second Rise LLC. (2022, MAR 27). https://www.lucidmeetings.com/meeting-types. Retrieved from

lucidmeetings.com: https://www.lucidmeetings.com/meeting-types