Is Bureaucracy Just Another Name For Governance?

Is Bureaucracy Just Another Name For Governance?

Fascinating opinion piece by Fisman and Sullivan in the Wall Street Journal on Friday (15 March 2013) called “The Unsung Beauty of Bureaucracy.”

The authors argue that bureaucratic rules and regulations serve important purposes in that while “less good stuff gets done–but it also puts a check on the kinds of initiatives that can lead to catastrophe.”

And they give numerous examples of industries that perform sensitive functions that you would want to actually take some extra time to make sure they get it right.

A vary basic example given was the company Graco that makes infant car seat and strollers; they have five design phases and hundreds of tests that add up to two years to product development, but who would rationally argue against such quality controls processes to protect our children.

They make another good point, we always here about bureaucracy slowing the innovation and product development down, but what about the “bad ideas that were quashed as a result of the same rules?”

We all rail against having to jump through hoops to get things done and rightfully so. The mission is important, time is of the essence, and resources are limited–last thing anyone wants is to be told you have x process that must be followed, y gates to get through, z signatures to obtain–and that’s just for the routine stuff! 🙂

But as much as we hate to be slowed down to cross the t’s and dot the i’s, often that’s just what we really need–to make sure we don’t do anything half-a*sed, stupid, or jut plain reckless.

One mistake in an operational environment can bring things to a standstill for thousands, in a system it can have a dominos effect taking down others, and in product development it can bring deadly consequences to consumers, and so on.

So putting up some “bureaucratic” hurdles that ensure good governance may be well worth its weight in gold.

Frankly, I don’t like the word bureaucracy because to me it means senseless rules and regulations, but good governance is not that.

We need to stop and think about what we are doing–sometimes even long and hard and this is difficult in a fast-paced market–but like a race car taking the turn too fast that ends up in a fiery heap–stopped not by their steady pacing, but by the retaining wall protecting the crowds from their folly.

One other thing the author state that I liked was their pointing out the government which is involved in so many life and death matters needs to maintain some heightened-level of governance (I’ll use my word), to get the food supplies safe and the terrorists out.

From clear requirements to careful test plans, we need to ensure we know what we are doing and that it will work.

At the same time, showing up after the party is over serves no purpose.

Like all things in an adult world, balance is critical to achieving anything real. 😉

(Source Photo: Andy Blumenthal)

SDLC On Target

Sdlc

I found this great white paper by PM Solutions (2003) called “Selecting a Software Development Life Cycle (SDLC) Methodology.”

The paper describes and nicely diagrams out the various SDLC frameworks:

– Waterfall
– Incremental
– Iterative
– Spiral
– RAD
– Agile

It also provides a chart of the advantages and disadvantages of each framework.

Finally, there is a simple decision cube (D3) based on time horizon, budget, and functionality for selecting an SDLC framework.

This is a very useful and practical analysis for implementing SDLC, and it aligns closely with the guidance from the National Institute of Science and Technology (NIST) Special Publication (SP) 800-64, “Security Considerations in the Systems Development Life Cycle” Appendix E that states:

“The expected size and complexity of the system, the development schedule, and the anticipated length of a system’s life may affect the choice of which SDLC model to use.”

While NIST focuses on the time horizon and complexity versus the PM Solutions Decision Cube that uses time horizon, budget, and functionality, the notion of tailoringSDLC to the project is both consistent and valuable.

Just one more resource that I found particularly good is the Department of Labor IT Project Management guidance (2002)–it is a best practice from the Federal CIO website.

I like how it integrates SDLC, IT Project Management, IT Capital Planning and Investment Control (CPIC), and security and privacy into a cohesive guide

It also establishes project “thresholds” to differentiate larger or more significant projects with greater impact from others and calls these out for “more intensive review.”

Even though these these resources are around a decade old, to me they are classic (in a good sense) and remain relevant and useful to developing systems that are on target.

(Source Photo: Andy Blumenthal)

Platforms – Open or Closed

Closed_open

Ever since the battles of Windows versus Linux, there have been two strong competing philosophies on systems architecture.

Many have touted the benefits of open architecture–where system specifications are open to the public to view and to update.

Open sourced systems provide for the power of crowdsourcing to innovate, add-on, and make the systems better as well as provides less vendor lock-in and lower costs.

Open Source —–> Innovation, Choice, and Cost-Savings

While Microsoft–with it’s Windows and Office products–was long the poster child for closed or proprietary systems and has a history of success with these, they have also come to be viewed, as TechRepublic(July 2011) points out as having an “evil, monopolistic nature.”

However, with Apple’s rise to the position of the World’s most valuable company, closed solutions have made a strong philosophical comeback.

Apple has a closed architecture, where they develop and strictly control the entire ecosystem of their products.

Closed systems provides for a planned, predictable, and quality-controlled architecture, where the the whole ecosystem–hardware, software and customer experience can be taken into account and controlled in a structured way.

Closed Systems —–> Planning, Integration, and Quality Control

However, even though has a closed solutions architecture for it’s products, Apple does open up development of the Apps to other developers (for use on the iPhone and iPad). This enables Apple to partner with others and win mind share, but still they can retain control of what ends-up getting approved for sale at the App Store.

I think what Apple has done particularly well then is to balance the use of open and closed systems–by controlling their products and making them great, but also opening up to others to build Apps–now numbering over 500,000–that can leverage their high-performance products.

Additionally, the variety and number of free and 99 cent apps for example, show that even closed systems, by opening up parts of their vertical model to partners, can achieve cost-savings to their customers.

In short, Apple has found that “sweet spot”–of a hybrid closed-open architecture–where they can design and build quality and highly desirable products, but at the same time, be partners with the larger development community.

Apple builds a solid and magnificent foundation with their “iProducts,” but then they let customers customize them with everything from the “skins” or cases on the outside to the Apps that run on them on the inside.

Closed-Open Systems —–> Planned, Integrated, and Quality PLUS Innovation, Choice, and Cost-Savings

Closed-Open Systems represent a powerful third model for companies to choose from in developing products, and which benefits include those from both open and closed systems.

>Staying Open to Open Source

>

I don’t know about you, but I have always been a pretty big believer that you get what you pay for.

That is until everything Internet came along and upended the payment model with so many freebies including news and information, email and productivity tools, social networking, videos, games, and so much more.

So when it comes to something like open source (“free”) software, is this something to really take seriously for enterprise use?

According to a cover story in ComputerWorld, 10 May 2010, called “Hidden Snags In Open Source” 61% say “open source has become more acceptable in enterprises over the past few years.” And 80% cited cost-savings as the driving factor or “No. 1 benefit of open-source software.”

However, many companies do not want to take the risk of relying on community support and so “opt to purchase a license for the software rather than using the free-of-charge community version…to get access to the vendor’s support team or to extra features and extensions to the core software, such as management tools.”

To some degree then, the license costs negates open source from being a complete freebie to the enterprise (even if it is cheaper than buying commercial software).

The other major benefit called out from open source is its flexibility—you’ve got the source code and can modify as you like—you can “take a standard install and rip out the guts and do all kinds of weird stuff and make it fit the environment.”

The article notes a word of caution on using open source from Gartner analyst Mark Driver: “The key to minimizing the potential downside and minimizing the upside is governance. Without that you’re shooting in the dark.”

I think that really hits the target on this issue, because to take open source code and make that work in a organization, you have got to have mature processes (such as governance and system development life cycle, SDLC) in place for working with that code, modifying it, and ensuring that it meets the enterprise requirements, integrates well, tests out, complies with security, privacy and other policies, and can be adequately supported over its useful life.

If you can’t do all that, then the open source software savings ultimately won’t pan out and you really will have gotten what you paid for.

In short, open source is fine, but make sure you’ve got good governance and strong SDLC processes; otherwise you may find that the cowboys have taken over the Wild West.

>Comments from OMB’s Chief Architect: Kshemendra Paul

>Recently, Kshemendra Paul, Chief Enterprise Architect, at the President’s Office of Management and Budget (OMB) made the following critical comments to me about business cases and pilots and incorporating these in the Systems Development Life Cycle:

“I was online and came across your site –
http://usercentricea.blogspot.com/2007/08/system-development-life-cycle-and.html.

I had two comments I wanted to share. First, I would recommend you highlight a business case step, a formal decision to move out of select/conceptual planning and into control. While this is implied, it is such a crucial step and we don’t do it well – meaning that we don’t force programs to work through all of the kinks in terms of putting forward a real business case (tied to strong performance architecture).

Also, this is a step that is inevitably cross boundary – either on the mission side and for sure on the funding side.

Second, I’d like to see more emphasis on smaller scale rollout or piloting. The goal of which is to prove the original business case in a limited setting. Nothing goes as planned, so another objective is to have real world data to refine the over all plan.”

I completely agree with Kshemendra on the need to develop business cases and do them well for all new initiatives.

Organizations, all too often, in their zeal to get out new technologies, either skip this step altogether or do it as a “paper” (i.e. compliance) exercise. Symbolic, but wholly without intent to do due diligence and thus, without any genuine value.

Therefore, whenever we plan for new IT, we must ensure strategic business alignment, return on investment, and risk mitigation by developing and properly vetting business cases through the Enterprise Architecture and Investment Review Boards.

It’s great to want to move quickly, get ahead of the pack, and gain competitive advantage by deploying new technologies quickly, but we risk doing more harm than good, by acting rashly and without adequately thinking through and documenting the proposed investment, and vetting it with the breadth and depth of organizational leadership and subject matter experts.

Secondly, as to Kshemendra’s point on doing pilots to prove out the business case. This is an important part of proofing new ideas and technologies, before fully committing and investing. It’s a critical element in protecting the enterprise from errant IT investments in unproven technologies, immature business plans, and the lack of ability to execute.

Pilots should be incorporated along with concept of operations, proof of concepts, and prototypes in rolling out new IT. (See my blog http://usercentricea.blogspot.com/2007/08/conops-proof-of-concepts-prototypes.html)

With both business cases and pilots for new IT projects, it’s a clear case of “look before you leap.” This is good business and good IT!

>Frameworks and Enterprise Architecture

>

One of the issues facing IT professionals these days isn’t a scarcity of IT frameworks, but rather many good frameworks that can be in conflict if we do not sort them out.

Usually each framework is focused on a certain lifecycle, which on one hand helps align it to a certain view on things, but on the other hand complicates things further, because each framework attempts to be all things to all people, by covering an entire lifecycle.

Here are some examples of the frameworks and their associated lifecycles:

  • Enterprise architecture – the IT investment life cycle (Capital Planning and Investment Control, CPIC)
  • SDLC—the Systems Development Life Cycle
  • ITIL –the service lifecycle
  • PMBOK—the project lifecycle
  • CMMi—the process lifecycle
  • Configuration Management—the asset lifecycle

Each framework has plans that need to be developed, processes to be followed, reviews that get conducted, and go/no-go decisions issued.

If an organization attempts to introduce and utilize all these frameworks then there can result a major overlap of structures, processes, and reviews that can literally drive a project manager or program sponsor nuts!

The organization could grind to a standstill trying to comply with all these frameworks.

I believe that each framework has useful information and guidance for the organization to follow and that the key to implementing these is to determine which is the PRIMARY framework at various stages of IT. The other frameworks may overlap in the stages, but it is the primary framework that guides that each stage.

Here’s an example using a few of these:

  1. Enterprise architecture is the decision making framework for IT systems. It has a core function in influencing IT investment decisions based on the target architecture and transition plan and EA reviews of proposed new IT projects, products, and standards. Therefore, EA is the primary or dominant framework in the planning stage of IT (up to the IT investment decision).
  2. SDLC is the development framework for IT systems. SDLC has a core function is guiding the software development process. As such, SDLC is the primary framework for the development phase of the system (which comes after the IT investment decision and before operations and maintenance). Of course, SDLC has planning phases and O&M and disposition phases as well, but SDLC is the primary framework only in the development stage.
  3. ITIL is the service framework. It has a core function in determining how service will be delivered and supported. ITIL is the primary framework for the O&M stage of the system (this comes after the development and before the disposition of the system), since that is when the system needs service delivery and support. Again, ITIL has other stages that overlap with other frameworks, for example planning and configuration management, but ITIL is the dominant framework only in the O&M phase.

The other frameworks should conceptually also assume a primary role for specific phases of IT and then pass off that role to the next framework that is dominant in that particular area.

4. For example, maybe PMBOK would have a dominant framework role also in the planning phase, looking at cost, schedule, performance, resources, risks, and so on (this would be after the IT investment decision of EA and before the development or acquisition phases). Again that is not to say that PMBOK doesn’t shed light and provide requirements for other stages of IT—it does—but it just is not the primary framework for those other stages.

I believe it is only by developing a unified lifecycle and assigning primary framework “ownership” to each stage will we be able to develop a truly workable IT structure and process for our organizations. As the saying goes: ”Two kings cannot sit on one throne.” So too, two frameworks cannot be simultaneously guiding our project managers and program sponsors nor taking up valuable IT resources.

The end goal is a single, simple, step-by-step process for our projects to follow with clear actions, milestones, and reviews, rather than a web of confusion and siloed, redundant governance processes in play.

>Portfolio Management and Enterprise Architecture

>

Enterprise architecture and portfolio management are closely linked activities. EA drives IT investment management (including the IT portfolio select, control, and evaluate phases) by conducting technical reviews of proposed new IT projects, products, and standards, and IT investment management provides important information updates to the EA (baseline, target, and transition plan).

In Architecture and Governance Magazine, Issue 3 Volume 2, Nuttall and Houghton provide an overall framework that goes “Beyond Portfolio Management to Comprehensive Application Governance.”

The framework includes three main areas and one supporting process area, as follows:

  1. Application and License Management (tactical)—“It manages the demand side and user requests, the contract and compliance aspects of determining the number of licenses that are contractually allowed, along with the projects that bring new products into the portfolio while retiring older products that have been removed. In many ITIL organizations, a help desk/service desk would handle the demand for applications, while the license management aspects are often assigned to the procurement and/or configuration management functions.”
  2. Application Portfolio Management (strategic)—“determines the appropriate mix of applications in the portfolio. It s highly dependent on the strategic business drivers for the corporation and includes: portfolio strategy development, optimization, and planning.” Portfolio strategy development determines the drivers and priority of those. Portfolio optimization determines the right mix of applications to support those goals. And portfolio planning determines the risks and constraints in implementing the portfolio, such as architecture, infrastructure, and resource constraints.
  3. Financial Management—“budget and forecasting, account management, and allocations management;” these enable the planning of what money is available for the portfolio and what money is spent for applications.
  4. Supporting Processes—other process areas that impact portfolio management include: “knowledge management, communications management, management reporting, architecture strategy, risk management, operational delivery, and support management.”

“One thing is certain, though, as technology continues to drive productivity, comprehension of application governance will become an even more essential step for companies wishing to manage their risks and costs while continuing to gain strategic value from their portfolios.”

I think this model is very helpful in decomposing the traditional definition of governance from the strategic functions of portfolio selection, control, and evaluation to the additional tactical, strategic, and financial aspects involved in managing it. Particularly, I believe it is useful to separate out the business demand (licenses, new systems and technologies) from the portfolio development and optimization (“the right mix” to satisfy user needs). Additionally, the breakout of financial management from the portfolio development is important in making the distinction between the roles of the Investment Review Board/Enterprise Architecture Board and the financial or resources group that actually budget and accounts for the funding aspect of IT spend.

Nuttall and Houghton do not go into any depth with the supporting processes, so these are presented as high level touch points or supporting processes without any particular explanation of how they support portfolio management and governance.

One critical item, the authors did not include, but should have included is the Systems Development Life Cycle, which take the IT portfolio and governs it from planning through analysis, design, development, testing, deployment, operations and maintenance, and ultimately to disposition. The success of moving systems projects through the SDLC will impact the make-up of future portfolio decisions.

>Do-It-Yourself (DIY) Application Development and Enterprise Architecture

>

The Wall Street Journal, 24 September 2007 reports that “new [DIY] tools let businesspeople avoid the IT department and create their own computer applications…and no knowledge of computer code is required.

How does this benefit users?

  • “Users say they are saving time and money by creating their own applications”
  • They “are able to build exactly what they want, without having to explain what their looking for to someone else.”
  • “Others like being able to wite programs that would have been too minor or personalized to bother the IT department with.”
  • “Adjusting DIY programs…can also be simpler than asking the IT department for program tweaks or updates.”

What are the downsides?

  • “There is some risk in the lack of a track recod for such companies [offering these DIY services], and in the possibility that a provider will fail, leaving its customers without access to the applications they developed online.”
  • “Some businesspeople may underestimate the effort required to write their own programs.”

Strangely enough, the article leaves out some of the biggest gaps with DIY application development, such as:

  • Approval by the organization’s IT governance to ensure that the ‘right’ projects are authorized, prioritized, funded and monitored for cost, schedule, and performance.
  • Compliance with an organization’s enterprise architecture to ensure such things as: business alignment, application interoperability and non-redundancy, technology standardization, information sharing, and strategic alignment to the target architecture and transition plan.
  • Assuring IT security of applications systems, including confidentiality, integrity, availability, and privacy.
  • Following a defined, repeatable, and measurable structured systems development life cycle (SDLC) approach to application development.

The WSJ article actually compares DIY application development to when businesspeople learned to create their own PowerPoints presentation rather than having to run to the graphics departments to build these for them.

While there may be a place for DIY application development for small user apps (similar to creating their own databases and presentations), from a User-centric EA perspective, we must be careful not to hurt the enterprise, in our efforts to empower the end-users. A balanced and thoughful approach is called for to meet user requirements (cost effectively and quickly), but at the same time protect enterprise assets, meet strategic goals, and assure overall governance of IT investments.

>SDLC, CPIC, PMBOK, and EA

>

User-centric EA seeks to align the various life cycle IT system processes to help users understand, navigate, and complete these as simply and smoothly as possible.

Below is an alignment of the processes for System Development Life Cycle (SDLC), Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and the Project Management Book of Knowledge (PMBOK).

SDLC

CPIC

EA

PMBOK

Conceptual Planning

Select

Business Alignment

Initiating

Planning & Requirements

Control

Technical Alignment

Planning

Design

Executing

Development & Testing

Implementation

Operations & Maintenance

Evaluate

Architecture Assessment

Disposition

Closing


The graphic demonstrates that the various IT system processes align quite nicely, and that user seeking to stand up a new system or make major changes to existing systems can follow the basic 7 steps of the SDLC and complete the requirements of CPIC, EA, and PMBOK along the way (the touch points are all identified).

The way to read this graphic is as follows:

For example, in the first phase of the SDLC, the conceptual planning stage, the user does the following: 1) defines their need (SDLC process) 2) develop their business justification and seek to obtain approval and funding from the IT Investment Review Board (CPIC process) 3) develops their business alignment and seeks approval from the Enterprise Architecture Board (EA process), and 4) define their project and seek authorization to proceed (PMBOK process).

For CPIC, users identify the following:

  • Select—How does the investment meet business decision criteria?
  • Control—Is the investment being managed with the planned cost, schedule, and performance criteria?
  • Evaluate—Did the investment meet the promised performance goals?

For EA, users demonstrate the following:

  • Business Alignment—Does the investment support the agency mission?
  • Technical Alignment—Does the investment interoperate within the technology infrastructure and meet technical standards?
  • Architecture Assessment—Is there a need to update the architecture?

For PMBOK, users complete various project management processes:

  • Initiating—Define and authorize the project.
  • Planning—Define objectives and plan course of action.
  • Executing—Integrates resources to carry out project management plan.
  • Closing—Accept product or service.

Note: The EA/CPIC alignment is adapted from Architecture Alignment and Assessment Guide, Chief Information Officers Council, August 2001. The PMBOK definitions are adopted from the Project Management Book of Knowledge, Third Edition.

User-centric EA promotes the alignment of the various IT system processes to help users to easily understand the touch points in the various life cycle steps to getting their system up and running. Moreover, the alignment enables the CIO to develop processes and job aids to assist and ‘speed’ users through the process. Thus, the processes are transformed from inhibitors to facilitators of systems progress for the enterprise.