Project Governance and Gate Reviews

Thought this may be helpful for those looking at a Governance Process and Gate Reviews for project management. 


This aligns the Capital Planning and Investment Controls (CPIC) process of select, control, and evaluate phases with the Systems Development Life Cycle (SDLC). 


There are 5 notional gate reviews with associated documentation for project conception, initiation, planning, execution, and launch.


Of course, this can be modified as needed based on the project threshold and governance stringency required and seeks to create strategic alignment with the goals of the organization. 


(Credit Graphic: Andy Blumenthal)

People, Process, and Technology Lifecycles

Lifecycles.jpeg

The table describes the alignment of the various people, process, and technology lifecycles commonly used in Information Technology to the CIO Support Services Framework (CSSF).


The CIO Support Services Framework describes the six key functional roles of the Office of Chief Information Officer (OCIO)–it includes:


1) Enterprise Architecture (Architect)

2) Capital Planning and Investment Control (Invest)

3) Project Management Office (Execute)

4) CyberSecurity (Secure)

5) Business Performance Management (Measure)

6) IT Service (and Customer Relationship) Management (Service)


All these OCIO Functions align to the lifecycles for process improvement (Process), project management (People), and systems development (Technology).


– The Deming Life Cycle describes the steps of total quality management and continuous process improvement (Kaizen) in the organization.


– The Project Management Life Cycle describes the phases of managing (IT) projects.


– The Systems Development Life Cycle describes the stages for developing, operating and maintaining application systems.


Note: I aligned cybersecurity primarily with doing processes, executing projects, and designing/developing/implementing systems.  However, cybersecurity really runs through all phases of the lifecycles!


My hope is that this alignment of people, process, and technology life cycles with the roles/functions of the OCIO will help bridge the disciplines and make it easier for people to understand the underlying commonalities between them and how to leverage the phases of each with the others, so that we get more success for our organizations! 😉


(Source Graphic: Andy Blumenthal)

Requirements Management 101

Requirements Management.jpeg.JPG

This was a funny Dilbert on Requirements Management. 


In IT, we all know that getting requirements can be like pulling teeth. 


No one either has time or desire to provide them or perhaps they simply don’t know what they’re really after.


Knowing what you want is a lot harder than just telling someone to automate what I got because it isn’t working for me anymore!


In the comic, Dilbert shows the frustration and tension between technology providers and customers in trying to figure out what the new software should do. 


Technology Person: “Tell me what you want to accomplish.”


Business Customer: “Tell me what the software can do.”


In the end, the customer in exasperation just asks the IT person “Can you design [the software] to tell you my requirements?”


And hence, the age old dilemma of the chicken and egg–which came first with technology, the requirements or the capability–and can’t you just provide it!


(Source Comic: Dilbert By Scott Adams)

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)

>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.

>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.

>IT Investment Reviews and Enterprise Architecture

>

To manage IT, you’ve got to have investment reviews, but when is it too much or not effective?

There are a number of executives (CXO’s) with a stake in the success of IT projects and a responsibility to review and manage them:

  1. Chief Financial Officer (CFO)— is interested in the investment’s alignment to the mission and its return on investment
  2. Chief Information Officer (CIO)—looks at IT projects in terms of technical alignment and compliance with the enterprise architecture, systems development life cycle, IT security, and other areas like privacy, accessibility, records management, and so on
  3. Chief Procurement Officer (CPO)—reviews projects for contractual issues to protect the organization and ensure that “it gets what it’s paying for”
  4. Line of Business (LOB) Program Officials—must review projects in terms of their project management and to control cost, schedule, and performance and ensure that the organization “controls” its investments

Usually, each of these executives has boards to carry out these review functions, and they are redundant, inefficient and drive the end-user crazy answering questions and checklists.

Part of the problem is that the executives and their review boards do not limit themselves to reviewing just their particular domains, but look across the management areas. So for example, EA often not only looks at technical alignment, but also will review business alignment and performance measures.

Moreover, not only are the review boards’ functionality often redundant between CXO’s, but even within the domain of a CXO, there will be duplicative review efforts such as between EA, SDLC, and IT security reviews.

Additionally, when an organizational component of an organization needs to conduct these reviews at their level and then again all the same reviews at a higher overall organization level, then the already inefficient review process is now doubly so.

In the end, with all the requisite reviews, innovation gets stifled, projects hamstrung, and the end-user frustrated and looking to circumvent the whole darn thing.

Obviously, you must review and establish checks and balances on IT investments, especially with the historical trends of people spending extravagantly and wastefully on IT solutions that were non-standard, not secure, not interoperable, did not meet user requirements, were over-budget, and behind schedule.

The key from a User-centric EA perspective is to balance the needs for governance, oversight, and compliance with helping and servicing the end-user, so they can meet mission needs, develop innovative solutions, and manage with limited resources. Asking users the same or similar checklist questions is not only annoying, but a waste of valuable resources, and a great way to spark an end-user revolt!

Remember it’s a fine line between EA and governance showing value to the organization and becoming a nuisance and a hindrance to progress.