Showing posts with label Capital Planning and Investment Control. Show all posts
Showing posts with label Capital Planning and Investment Control. Show all posts

January 18, 2020

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)
Share/Save/Bookmark

May 25, 2011

Apples or Oranges

There are lots of biases that can get in the way of sound decision-making.

An very good article in Harvard Business Review (June 2011) called "Before You Make That Big Decision" identifies a dozen of these biases that can throw leaders off course.

What I liked about this article is how it organized the subject into a schema for interrogating an issue to get to better decision-making.

Here are some of the major biases that leaders need to be aware of and inquire about when they are presented with an investment proposal:


1) Motivation Errors--do the people presenting a proposal have a self-interest in the outcome?

2) Groupthink--are dissenting opinions being actively solicited and fairly evaluated?

3) Salient Analogies--are analogies and examples being used really comparable?

4) Confirmation Bias--has other viable alternatives been duly considered?

5) Availability Bias--has all relevant information been considered?

6) Anchoring Bias--can the numbers be substantiated (i.e. where did they come from)?

7) Halo Effect--is success from one area automatically being translated to another?

8) Planning Fallacy--is the business case overly optimistic?

9) Disaster Neglect--is the worst-case scenario imagined really the worst?

10) Loss Aversion--is the team being overly cautious, conservative, and unimaginative?

11) Affect Heuristic--are we exaggerating or emphasizing the benefits and minimizing the risks?

12) Sunk-Cost Fallacy--are we basing future decision-making on past costs that have already been incurred and cannot be recovered?

To counter these biases, here are my top 10 questions for getting past the b.s. (applying enterprise architecture and governance):

1) What is the business requirement--justification--and use cases for the proposal being presented?

2) How does the proposal align to the strategic plan and enterprise architecture?

3) What is return on investment and what is the basis for the projections?

4) What alternatives were considered and what are the pros and cons of each?

5) What are the best practices and fundamental research in this area?

6) What are the critical success factors?

7) What are the primary risks and planned mitigations for each?

8) What assumptions have been made?

9) What dissenting opinions were there?

10) Who else has been successful implementing this type of investment and what were the lessons learned?

While no one can remove every personal or organizational bias that exists from the decision-making equation, it is critical for leaders to do get beyond the superficial to the "meat and potatoes" of the issues.

This can be accomplished by leaders interrogating the issues themselves and as well as by establishing appropriate functional governance boards with diverse personnel to fully vet the issues, solve problems, and move the organizations toward a decision and execution.
Whether the decision is apples or oranges, the wise leader gets beyond the peel.

Share/Save/Bookmark

September 11, 2010

Toward A Federal Enterprise Architecture Board


A Federal Enterprise Architecture Board (FEAB) would provide “teeth” to further implementing enterprise architecture across government.

We have a Federal Enterprise Architecture (FEA) that provides a government wide framework for architecture strategy and planning, but we do not have a FEA Board to govern the subsequent IT investments through capital planning and investment control (CPIC). CPIC is the governance process whereby we select, control, and evaluate new IT investments.

Interestingly, The Federal CIO Council’s Architecture Alignment and Assessment Guide (October 2000) specifically calls for complementary EA and CPIC functions (see graphics).

In this paradigm, the enterprise architecture (EA) informs, guides, drives the CPIC, and in turn the decisions from the CPIC governance process updates the EA planning, so that the EA and CPIC processes are seen as mutually supportive.

In the federal government, we have departmental and agency architectures and boards that serve to plan and govern IT investments at their respective levels. However, as we seek to build greater standardization, interoperability, and reuse across government with IT initiatives that cut across traditional government boundaries driven and guided by the Federal CIO and Federal CIO Council, there is a need for a FEAB to review new and major changes to IT investments.

There would be many purposes for the FEAB.

  • Strategic alignment: One would be to ensure strategic alignment not to any single department or agency mission, but rather to the greater federal government strategy and policy. Some examples of this would be data center consolidation, green IT, open government, and more.
  • Streamlining of investments: Additionally, the FEAB would assess IT investments to ensure that there is no overlap or opportunities for consolidation of initiatives. OMB performs some of this function today, but a FEAB would augment their capability with IT subject matter experts from across the government.
  • Other key benefits: Of course, the FEAB would also look at things like return on investment measures, risk mitigation plans, technical compliance to federal architecture standards and mandates (security, privacy, records, FOIA, Section 508, etc.).

The FEAB would not be a substitute for the EA Boards that provide oversight functions at the department and agency levels, but would provide governance for the largest and riskiest IT initiatives and those that cut across different agencies.

While the OMB currently assesses IT investments using Exhibits 300s and 53s, which include EA assessment questions, the FEAB would provide a governance board made up of cross-cutting governmental IT subject matter experts to vet these business cases from an EA perspective thoroughly and provide recommendations to the Federal CIO Council and the OMB on approval or denial. Therefore, and not unimportantly, the stand-up of a FEAB would add an important human factor to the Federal Enterprise Architecture and make it “real.”

Of course, with a portfolio of some 10,000 IT systems, the FEAB would not be able to govern every new Federal IT investment. Therefore, it would be critical to establish thresholds that would be practical for implementation.

I would envision the FEAB being chaired by the Federal Architect and the board being a recommendation body to the Federal CIO Council and the Office of Management and Budget, Executive Office of the President.

Critical initiatives by Federal CIO Vivek Kundra to effectively manage (i.e. CPIC control phase) IT investments through the Federal IT Dashboard and TechStat sessions would be augmented by the FEAB work to carefully recommend for selection (i.e. CPIC select phase) new federal IT investments.

Together, I see the federal select and control mechanisms of CPIC functioning in harmony to enhance governments IT planning, investment decision-making, and execution. Essentially, the FEA (architecture) and FEAB (governance) on the “front-end” will guide new IT investments, and the IT Dashboard and TechStat sessions on the “back-end” will ensure IT investments are properly progressing for the taxpayer based on cost, schedule, and performance measures.

In summary, the Federal Enterprise Architecture Board would be the governance arm of the Federal Enterprise Architecture, and serve as a support to the IT leadership of the Federal CIO, the Federal CIO Council, and the IT budgetary functions performed by the Office of Management and Budget.

Share/Save/Bookmark

August 29, 2010

Why EA and CPIC?

Note: This is not an endorsement of any vendor or product, but I thought this short video on enterprise architecture planning and capital planning and investment control/portfolio management was pretty good.


Share/Save/Bookmark

September 21, 2009

Testing EA in Virtual Reality

In enterprise architecture, we develop IT targets and plans for the organization, but these are usually not tested in any meaningful or significant way, since they are “future tense”.

Wouldn’t it be incredible to be able to actually test EA hypotheses, targets, and plans in a virtual environment before actually setting off the organization in a specific direction that can have huge implications for its ability to conduct business and achieve results?

MIT Technology Review, in an article entitled “The Fleecing of the Avatars” (Jan/Feb 2008) addresses how virtual reality is being used to a greater extent to mimic and test reality.

One example of the booming virtual world is Second Life, run by Linden Labs. It has 10,000,000 subscribers and “about 50,000 are online at any one time.” In this virtual world, subscribers playing roles as avatars “gather to role-play reenactments of obscure digital Star Trek cartoon episodes, build and buy digital homes and furniture, and hang out on digital beaches.”

However, more and more virtual worlds, like Second Life, are being used by real world mainstream businesses. For example, many companies are developing a presence in the virtual world, such as Dell with a sales office in Second Life, Reebok a store, and IBM maintains business centers in this virtual world. Further, “the World Bank presented a report in Second Life about business development.”

“But big companies like Sun, Reebok, and IBM don’t really do business in virtual worlds; they ‘tunnel’ into them. [In other words,] To close a deal, you need to step out of the ‘sim’ and into the traditional Sun or Reebok or IBM website.”

The development of company’s virtual presence online and their connection back to the real world is potentially a precursor to planning disciplines like EA testing out hypotheses of targets and plans in virtual reality and then actually implementing these back in the real organization.

Others are actually planning to use virtual worlds to test and conduct research. So there is precedent for other disciplines such as EA. For example, Cornell’s Robert Bloomfield, an experimental economist, “conducts lab research—allowing 20 students to make simulated stock trades using real money…and seeing how regulatory changes affect their behavior. He envisions a day when he can do larger studies by setting up parallel virtual worlds. ‘I could create two virtual worlds, one with legal structure, one with another, and compare them…I might lower the capital-gains tax in one and see how business responds. There are things I can’t do with 20 people in a classroom but I can do with 2,000 or 20,000 people in a virtual world.”

Could enterprise architecture do something similar in a virtual world? For example, could we test how business processes need to change when new technology is introduced or how information sharing improves with better architectures for discovering and exchanging data? How about testing people’s reactions and behavior to new systems in a broader virtual world instead of with a more limited number of customers in user acceptance testing? Another possibility is testing the effectiveness of new IT security in a virtual world of gamers and hackers?

Modeling and simulation (M&S) can improve enterprise architecture by testing plans before deploying them. We need to to hire and train people with knowledge, skills, and experience in the M&S discipline and with tools that support this. Then we can test hypothetical return on investment for new IT investments before we open our organizational wallets.


Share/Save/Bookmark

August 7, 2009

How to Strengthen the Office of the CIO - Part II

Punlished at Government Technology

[Editor's Note: This article is the second in a series that explores the CIO Support Services Framework in government.]

In Part 1 of The CIO Support Services Framework, I presented the six major components needed to support the public CIO in managing IT strategically and proactively. In this article, I will explain what IT best practices framework inform these six components and propose a structure for implementing it.

The six CIO Support Services Framework (CSSF) functions are distinct areas that require subject-matter expertise and need to be managed based on the various IT best practice frameworks. While I am not endorsing any particular best practice government or industry framework, below is a sampling according to CSSF functional area:

Enterprise Architecture (EA) -- Federal Enterprise Architecture (FEA), Department of Defense Architecture Framework (DoDAF), and The Open Group Architecture Framework (TOGAF).

Capital Planning and Investment Control (CPIC) -- Office of Management and Budget (OMB) Circular A-130--"Management of Federal Information Resources" and the Control Objectives for Information and related Technologies (COBIT) by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI).

Project Management Office (PMO) -- the Project Management Book of Knowledge (PMBOK) by the Project Management Institute is the de facto standard project management best practices from initiation through project closeout.

Customer Relationship Management (CRM) -- the IT Infrastructure Library (ITIL) by the United Kingdom's Office of Government Commerce (OGC) and International Standards Organization (ISO) 20000--"IT Service Management." While both are very much operational frameworks, they can also be used to guide service and support at a strategic level in the OCIO.

IT Security (ITS) -- the Federal Information Security Management Act (FISMA), various Federal Information Processing Standards (FIPS) from the National Institute of Science and Technology (NIST), and International Organization for Standardization ISO/IEC 17799 -- Information Technology Code of Practice for Information Security Management.

Business Performance Measurement (BPM) -- the Balanced Scorecard (BSC) by Kaplan and Norton from Harvard Business School -- examines financial, customer, internal business process, and learning and growth measures for the organization.

Although each of the six main functional areas and their supporting best practice frameworks are unique, they can and will overlap, and it is imperative that the OCIO develop a simple and streamlined process for managing these, so that IT and business personnel are not confused or burdened by redundant or circuitous IT processes that hinder, rather than spur innovation and agility. For example, while EA planning guides CPIC IT investment decisions, those decisions inform the next round of EA planning -- it is inherently cyclical. Nevertheless, we must ensure that the overall process flow between all six areas is as clear and simple as possible.

I like to use the example of a Monopoly game board as an analogy for how IT processes should ideally progress from "Go" all the way through -- logically, and more or less sequentially -- without project mishap, ending up on the OMB Watch List for risky IT projects, the equivalent of landing in Monopoly "jail."

The CSSF provides the functional resources to fully support the OCIO and provide the capability to move from simply fighting day-to-day operational problems to strategically managing IT service provision, improving performance and increasing program and project success, through:

Planning (EA)

Investing (CPIC)

Executing (PMO)

Servicing (CRM)

Securing (ITS)

Measuring (BPM)

Each of these OCIO component functions is helpful in managing IT by providing the CIO the capability to better plan, invest, execute, service, secure and measure -- but these are not stand-alone functions -- they are all necessary and complementary.

An organization can have the best EA plan, but without the structured investment processes of CPIC, the plan will not drive, guide, influence and shape IT investment decision-making. In fact, I would propose that CPIC is an enforcement mechanism for carrying out the EA plan.

Similarly the organization can have a wonderful CPIC process for making IT investment decisions, but without a PMO to develop and enforce sound PM policies and practices, IT projects will continue to fail miserably. With an effective PMO, we will have more successful project execution, but without CRM to manage customer requirements and service and support issues, we run a very high risk of rolling out IT capabilities that the customer neither wants nor is happy with. Further, CRM will increase customer satisfaction, but without ITS, CIOs will not ensure the security of the information and systems that the users are depending on.

Finally, with ITS, CIOs will provide users for information security, but without BPM, will miss the opportunity to perform structured performance measurement and management, so that the CIO has visibility to how IT is performing in all areas and on an ongoing basis and can take timely corrective action as needed.

Most organizations either don't do any of these CSSF functions well or they don't do them all. The six components need to be executed together -- the whole being greater than the sum of its parts. Further, I would propose that the six CSSF functions be implemented under the auspices of the CTO of the organization in order to centralize and holistically manage the functions in support of the CIO.

The result is that the CIO is better supported, without being overwhelmed, and the CTO has a clear mandate for strategically implementing the CIO's vision for the organization.

Of course, one of the biggest challenges to implementing the CSSF is finding and allocating the needed funding to support these OCIO functions. IT operations tend to be underfunded already and stuck in the perpetual firefighting mode. Executives often fearf siphoning the needed money or people away from the short-term firefight to work on long-term strategy and implementation. This is a serious mistake!

Firefighting is a losing battle if you attack only the symptoms, but never address the cause or core strategic issues. Moreover, in the fast-paced technology environment of the 21st century, no IT leader can afford to be looking backward -- managing legacy systems that do not leverage modern technologies, techniques and methodologies for information sharing, collaboration and business intelligence.

If you are spending close to 100 percent on IT operations today, is it really unreasonable to allocate 3 to 5 percent of this to strategy, planning and control? Of course, this needs to adjust when IT budgets get extremely large or small and as the complexity of the organization shifts.

As the prior chief enterprise architect of the U.S. Coast Guard and of the United States Secret Service, I have always been a deep proponent of EA and CPIC to drive better IT investment decision-making. However, now as the chief technology officer (CTO) of the Bureau of Alcohol, Tobacco, Firearms and Explosives, I more fully understand how the CSSF functions and interplay are needed for the CIO to perform effectively.

Clearly EA and CPIC are not enough to adequately support the CIO's needs, and thus, they need to be extended with PMO, CRM, ITS and BPM. Moreover, these areas function best that function together for the reasons I mentioned prior -- it's a clear domino effect, where astute planning, sound governance, skilled project management practices, competent customer service, solid IT security and meaningful performance measurement are all necessary for the CIO to manage IT more strategically and effectively.??This is why I firmly believe that the CIO Support Services Framework is how we are going to have to manage IT to achieve genuine success for the CIO in the 21st century and beyond.

_______________________________________

Andy Blumenthal is chief technology officer at the Bureau of Alcohol, Tobacco, Firearms and Explosives. A regular speaker and published author, Blumenthal blogs at User-Centric Enterprise Architecture and The Total CIO. These are his personal views and do not represent those of his agency.


Share/Save/Bookmark

August 6, 2009

How to Strengthen the Office of the CIO - Part I


Published at Government Technology
[Note: This is a two-part article on strengthening the office of the CIO to improve IT operations. Part 1 examines the six components of a CIO Support Services Framework. Part 2 will explore best practices and implementation.]
Information technology is plagued with what federal CIO Vivek Kundra recently called "magnificent failures." A recent research survey by theStandish Group identified that more than 80 percent of IT projects were either failing or significantly at risk. Another article described the CIO's role as a nearly impossible job, trying to manage day-to-day firefighting with limited to no ability to get control and manage strategically.
We are investing massive sums of money, time and effort, only to disappoint customers, miss the mark on requirements and fail to deliver on time, within budget and to specifications.
The CIO Support Services Framework (CSSF) is an approach for changing the dynamic of failed IT projects and putting the CIO and other IT leadership back in the driver's seat, by ensuring that the structural components for success are identified, elevated and resourced appropriately.
The focus of this article is to identify, describe and link the core elements that make up and support an Office of the CIO for the purpose of demonstrating how that will lead to improved IT operations. When the CIO is properly supported, program and project management can be executed with strategic intent and alignment.
It is not my aim to discuss the pros and cons of the many solid approaches to IT project and program management today, such as the Federal Enterprise Architecture (FEA), Information Technology Infrastructure Library (ITIL), Control Objectives for Information and related Technology (COBIT), Project Management Body of Knowledge (PMBOK), Federal Information Processing Standards (FIPS) and International Organization for Standardization (ISO) 20000. I will say that while each is comprehensive in its own right, they are skewed by a particular emphasis on a particular function. For instance, FEA looks at architecture planning, ITIL on service support and delivery, PMBOK on project management and so on. What the CIO needs for ultimate success is a way to incorporate elements of all of these perspectives into a bigger picture.

Image copyright by Andy Blumenthal
So what is the CSSF? It is an IT framework aimed at standing up and strengthening an office of the CIO so that it can lead strategically and drive improved IT operations. The idea is that just as business drives (or ought to drive) technology within the greater organization, so too within the function of IT, the CIO and his or her strategy must drive technology operations rather than just fighting fires.
In the typical IT organization, CIOs are expected to be both strategist and problem-solver, with little supporting strategic infrastructure to guide, influence, shape and drive their key decisions about IT operations. All too often, problems crop up and even the most skilled and well intentioned CIOs are left to make decisions based on gut, intuition, politics and subjective management whim.
Even if the CIO has an IT governance board to shoulder some of this responsibility, together they are still like blind people grasping in the dark for answers. This framework corrects the structural defects in today's IT organization that cause this situation to occur.
The CSSF has six major components:
1. Enterprise Architecture (EA) -- for strategic, tactical, and operational planning in the organization. EA includes all perspectives of the organization's architecture including: performance, business, information (data and geospatial), services or systems), technology, security, and human capital (this last one is currently missing from the Federal Enterprise Architecture).
In EA planning, we develop the current architecture--where we are today in terms of business and technology resources, the target--where we want to be in the future through business process improvement and technology enablement, and the transition plan--how do we get from where we are today to where we want to be in the future.
More mature EA's provide business, data, and systems models, and identify gaps, redundancies, inefficiencies, and opportunities in the business and IT and recommend business process improvement, reengineering, and new technologies to improve organizational performance.
2. Capital Planning and Investment Control (CPIC) or IT governance -- manages the IT investment decision processes of selecting, controlling, and evaluating new or major changes to the IT portfolio ( i.e. to put those plans to work and make them pay-off). CPIC can ensure that IT investments maximize return on investment, minimize or mitigate risk and provide for strategic alignment to the business.
CPIC also helps make IT investments technically compliant by ensuring that desirable IT behaviors are followed, such as information sharing and quality, interoperability, component reuse, standardization, simplification, cost-efficiency, and of course security.
3. Project Management Office (PMO) -- oversees the effective execution on the IT projects. These projects derive from the EA technical roadmap and transition strategy and from IT investment decisions coming out of the governance board(s) in CPIC. Project management is how we manage all facets of a project to include scope, schedule, cost, quality, project resources, integration, communications, and more, from the initiation of a project through its closeout. Project managers typically develop the work breakdown structures, project schedules, and monitor and manage progress to these.
4. Customer Relationship Management (CRM) or IT service management -- for managing service and support to our customer with "one call does it all". As opposed to customer management within IT operations which is focused on helpdesk, availability, break-fix, and support issues, CRM in support of the CIO is focused on serving as IT liaisons to the business responsible for overall customer satisfaction, generating and managing customer requirements, supporting business case development, and handling internal business complaints, issues, and coordinating problem resolution with IT operations.
5. IT Security (ITS) -- how we conduct IT security policy and planning. This function encompasses how we plan, assess, and enforce IT security, and not the actual implementation of IT Security, which is an operational IT function. This functional area includes preparing certifications and accreditations, risk assessments, security plans, vulnerability testing, security awareness training, and security policies. IT security ensures the confidentiality, availability, integrity, and privacy of the organizations information.
6. Business Performance Management (BPM) -- how we measure and drive performance, so we know whether we are hitting the EA target or not. BPM involves identifying performance measures, capturing, analyzing and reporting on metrics, and providing the CIO with IT executive dashboard views to inform which programs and projects that are on track, challenged and in jeopardy of failure.
Typically BPM provides for a drill-down capability, so high-level "red-yellow-green" program/project indicators and milestones can be decomposed into lower levels of detail for trends, analysis and making course corrections. BPM should provide a feedback mechanism for how the IT function is performing and drive continuous process and performance improvement in the CIO organization.
Together these six areas make up a holistic and synergistic set of support functions constitute a fully capable Office of the Chief Information Officer (OCIO) in the center.
In creating a strong OCIO, the CIO Support Services Framework wisely separates the policy, planning and oversight functions from the IT operations. This is beneficial in two main ways: First, this enables the CIO to strategically and proactively direct IT operations, rather than being in perpetual firefighting and reactive mode. Second, the separation of duties -- strategy from operations -- creates a healthier organizational dynamic and interplay in IT, where the fox is not left guarding the chicken coop.
Part 2 of this article will explore IT best practice frameworks and implementation of the CIO Support Services Framework.
_____________________________________
Andy Blumenthal is chief technology officer at the Bureau of Alcohol, Tobacco, Firearms and Explosives. A regular speaker and published author, Blumenthal blogs at User-Centric Enterprise Architecture and The Total CIO. These are his personal views and do not represent those of his agency.

Share/Save/Bookmark

July 4, 2009

CIO Support Services Framework

The CIO Support Service Framework (CSSF) has 5 major components:
  1. Enterprise Architecture--for strategic, tactical, and operational planning
  2. Capital Planning & Investment Control (or IT governance)--for managing the IT investment decision process (i.e. "putting those plans to work")
  3. Project Management (or a project management office)--to effectively execute on the programs and projects in the transition strategy
  4. Customer Relationship Management (or IT service management)--for managing service and support to our customer (i.e. with a single--belly button; one call does it all)
  5. Business Performance Management--how we measure & drive performance (like with an IT executive dashboard--so we know whether we are hitting the target or not!)
Together these five areas make up a holistic and synergistic set of CIO support functions.

So that we move the mindset of the CIO from fighting day to day operational problems to instead strategically managing IT service provision through:
  • Planning
  • Investing
  • Executing
  • Servicing
  • Measuring
This is how we are going to achieve genuine success for the CIO in the 21st century and beyond.


Share/Save/Bookmark

June 4, 2008

Good to Great and Enterprise Architecture

What makes a good organization become great in terms of technology?

In the book, Good to Great by Jim Collins, the author describes a five year study conducted in organizational greatness and what makes a good enterprise become great. Here are some finding in terms of achieving technology success:
  • Align technology with your mission—the key question that drives the enterprise’s technology is whether it fits directly with “what you are deeply passionate about…what you can be the best in the world at…[and] what drives your economic engine.”Through the User-centric EA target architecture, transition plan, and IT governance, EA moderates new investments in IT so they align with mission requirements and priorities.
  • Technology enables mission execution—“Good-to-great companies used technology as an accelerator of momentum, not a creator of it…a company can’t remain a laggard and hope to be great, but technology by itself is never a primary cause of either of greatness or decline." User-centric EA synthesizes business and technology information to enhance decision-making. EA ensures that the organization’s technology direction and investments enable mission.
  • Culture of discipline—Good-to-great companies have disciplined thought and action. They “respond with thoughtfulness and creativity, driven by a compulsion to turn unrealized potential into results; mediocre companies react and lurch, motivated by fear of being left behind." User-centric EA is a structured approach to managing and integrating business and technology. EA ensures that the organization follows an adaptable plan and does not get lurched around by the changing market, competition, or technology tides.
  • Change incrementally—“‘crawl, walk, run’ can be a very effective approach, even during times of rapid and radical technological change.” User-centric EA develops the target and transition plan for the organization, which ensures an approach of incremental change. New IT investments and business process improvements are done in a phased approach, rather than trying to “eat the elephant in one bite.”
In short, User-centric EA is a perfect fit with the conclusions of Jim Collins research into good-to-great companies.
Share/Save/Bookmark

March 3, 2008

IT Portfolio Management and Enterprise Architecture

IT portfolio management (ITPfM) is the application of systematic management to large classes of items managed by enterprise Information Technology (IT) capabilities. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios.

Debates exist on the best way to measure value of IT investment. As pointed out by Jeffery and Leliveld (2004), companies have spent billions of dollars into IT investment and yet the headlines of misspent money are not uncommon…IT portfolio management started with a project-centric bias, but is evolving to include steady-state portfolio entries such as application maintenance and support, which consume the bulk of IT spending. (Wikipedia)

  • ITPfM is related to the federal requirement for capital planning and investment control (CPIC), especially the select phase in which investments are authorized and funded.

The IT Management Reform Act of 1996 (Clinger-Cohen Act) specifies that executive agencies “establish effective and efficient capital planning processes for selecting, managing [controlling], and evaluating the results of all its major investments in information systems.

The Architecture Alignment and Assessment Guide by the Federal CIO Council, November 2000 defines capital planning and investment control (CPIC) as—“a management process for ongoing identification, selection, control, and evaluation of investments in information resources.”

  • CPIC/ITPfM and EA are closely linked processes. Enterprise architecture conducts technical reviews of proposed new IT projects, products, and standards and provides findings and recommendations to the IT Investment Review Board for decision-making on authorizing, prioritizing, and funding IT.

The Architecture and Assessment Guide states that “CPIC and enterprise architecture functions are closely linked…both have a common focus: the effective and efficient management of IT investments.

Further, the Office of Management and Budget (OMB) Circular A-130 requires that agencies establish and maintain a CPIC process and that they “must build from the agency’s current enterprise architecture.”

According to the Architecture Alignment and Assessment Guide, the three phases of CPIC align to EA as follows: CPIC’s select, control, and evaluate align to EA business alignment, technical alignment, and architecture assessment.

The Journal of Enterprise Architecture, February 2008, has an article by George Makiya that discusses “Integrating EA and IT Portfolio Management Processes”.

Makiya states “at the strategic level, the EA has to agree with the business side, what objectives the IT portfolio will be designed to achieve. It is imperative that the EA negotiate with the business side what constitutes value-add. The EA must then use ITPfM to engage the business to document or articulate its strategy and business objectives.”

Further, “at the operational level, the EA using ITPfM employs prioritization and selection processes to ensure that IT investment reflects the objectives and priorities of the business…through proactive management EAs can help the CIO align the IT budget with the demands of the portfolio.”

According to the Federal Enterprise Architecture Practice Guidance, November 2007, the performance improvement lifecycle starts with the agency’s strategy, and then has the three phases of architect (“develop and maintain EA”), invest (select investments and “define the implementation and funding strategy”, and implement (“execute projects”), which in turn yields strategic results.

  • Generally speaking, ITPfM decisions are made on the basis of return on investment, risk mitigation, strategic alignment, and technical alignment to the EA.

There are many touch points and linkages between EA and CPIC.

  • EA’s target architecture and transition plans drives the investments and portfolio make-up in the CPIC process.
  • CPIC investments are used to provide updates on systems, technologies, and standards to the EA.

EA and CPIC/ITPfM are truly mutually dependent and create synergy and value for the organization through enhanced decision making and IT resource control.


Share/Save/Bookmark

February 11, 2008

IT Governance –Value Creation and Accountability

IT governance is something people tend to have a love/hate relationship with. They love it because they know they need it and will benefit from it; but they hate it because they don’t want to do it and be bound by it.

It sort of reminds me of the old TV show, The Little Rascals, when the mother “makes” her kid take the spoonful of awful tasting castor oil because it was good for him. And what a face the kid would make as that spoon glided into his mouth, and then a big smile would emerge.

DM Review, 8 February 2008, reports that enterprises are “Getting Serious about IT Governance.”

Here’s why IT governance is growing in importance:

  1. Growing IT expenditures—“Worldwide IT spending has grown 5 percent to 8 percent in recent years and will approach $3 trillion for 2007”
  2. IT project troubles—“IT project failures, security breaches, and compliance snafus are still abundant. Gartner estimated that more than $600 billion has been squandered on ill-conceived or poorly executed projects. And according to Standish Group, only 30 percent of projects are considered successful.”
  3. Money won’t solve the problem—“Simply pouring more money into IT won’t necessarily fix a company’s problems or mitigate its risks.”

IT governance is a two-fold endeavor:

  1. Value creation—“IT governance is about balancing the interests of investors and stakeholders by focusing resources on the creation of value…if the mission of IT is to provide systems the business wants, it is equally important to provide systems the business actually needs.”
  2. Accountability—“IT governance is the system by which IT is directed and controlled. It should address the roles and responsibilities of groups and individuals…articulate the rules and procedures for making IT decisions, and provide a structure through which IT objectives are set, attained, and monitored.”

In the Federal IT Investment Management (ITIM) process for Capital Planning and Investment Control, value creation and accountability align well with the phases of Select-Control-Evaluate for IT investments.

  • The Select phase supports value creation. It involves the selection of projects based on a combination of the following factors: alignment with mission/business strategy, highest return on investment, lowest risk, and alignment to and compliance with the enterprise architecture.
  • The Control phase supports accountability. It involves monitoring and managing IT projects for cost, schedule, and performance parameters. Projects that deviate from their targets risk being reorganized, downsized, or entirely phased out.
  • The Evaluate phase supports both value creation and accountability. It is the evaluation of whether IT projects meet their intended performance goals. This provides lessons learned for future IT project selections and for controlling their steady progress, as well as holding accountable the project sponsor and team for their IT project.

Share/Save/Bookmark

January 22, 2008

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.


Share/Save/Bookmark

November 14, 2007

Diffusion of Innovation Theory and Enterprise Architecture

According to Everett Rogers’ Diffusion of Innovations (DOI) Theory, adopters of any new innovation or idea can be categorized based on the bell curve, as follows:
  • Innovators (2.5%) — most likely to conceive and develop new methodologies and technologies; the most daring and especially prone to taking risks
  • Early Adopters (13.5%) — a person who embraces new technology before most other people do.
  • Early majority (34%)
  • Late majority (34%)
  • Laggards (Luddites) (16%) — slow or reluctant to embrace new technology; actively fear or loathe new technology, especially those they believe threaten existing jobs.

Each adopter's willingness and ability to adopt an innovation would depend on their awareness, interest, evaluation, trial, and adoption. People could fall into different categories for different innovations -- a farmer might be an early adopter of hybrid corn, but a late majority adopter of VCRs.

When graphed, the rate of adoption formed what came to typify the DOI model, an “s shaped curve.” (S curve) The graph essentially shows a cumulative percentage of adopters over time – slow at the start, more rapid as adoption increases, then leveling off until only a small percentage of laggards have not adopted. (Rogers Diffusion Of Innovations 1983)

From a User-centric EA perspective, each of these user roles is important and needs to be considered in providing useful and useable information products and governance services to them.

On one hand, for the innovators and early adopters, User-centric EA encourages innovation and creativity, but also works to mitigate risk though business and technical alignment and architectural assessment related to sound capital planning & investment control.

On the other hand, for the laggards, User-centric EA set targets for technology adoption and phases in new technology and process according to a transition plan. While EA cannot “make” people less hateful of new technology, it can create a more controlled environment for change management in the enterprise, one which reduces the fear factor. Additionally, by EA demonstrating the benefits to the organization and the individuals therein of new technologies aligned to the mission and strategy of the organization, perhaps those who fear the technology will come around to embrace it.
Share/Save/Bookmark

October 1, 2007

The Hype Cycle and Enterprise Architecture

“A Hype Cycle (term coined by Gartner) is a graphic representation of the maturity, adoption and business application of specific technologies.

Hype cycles characterize the over-enthusiasm or "hype" and subsequent disappointment that typically happens with the introduction of new technologies. Hype cycles also show how and when technologies move beyond the hype, offer practical benefits, and become widely accepted.

The hype cycle comprises 5 steps:

  1. "Technology Trigger" breakthrough, product launch or other event that generates significant press and interest.
  2. "Peak of Inflated Expectations" frenzy of publicity typically generates over-enthusiasm and unrealistic expectations.
  3. "Trough of Disillusionment" Technologies fail to meet expectations and quickly become unfashionable.
  4. "Slope of Enlightenment" some businesses continue to experiment and understand the benefits and practical application of the technology.
  5. "Plateau of Productivity" the benefits become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations.

Hype cycles aim to separate the hype from the reality, and enable executives to decide whether or not a particular technology is ready for adoption.” (adapted from Wikipedia)

The Hype Cycle is a tool that can be used by EA to help evaluate new technologies and whether it’s the “right” time to jump in and invest.

The hype cycle teaches us not to be blind, bleeding edge technology adopters, but rather to allow ample time for the technologies and their applications to mature. Often a swift follower can implement a relatively new technology cheaper, faster, and better than those on the bleeding edge: the kinks have been worked out, the patches applied, and the applicability fleshed out. More important, those technologies that were more hype than substance have been eliminated from the mix.

While early adoption can be a winning strategy (and extremely lucrative) for those gifted to recognize and be able to apply real innovations early on, in most cases, the swift follower is the big winner and the bleeding edge adopter the loser.


Share/Save/Bookmark

September 21, 2007

Murphy’s Law and Enterprise Architecture

Murphy's law is an adage in Western culture that broadly states that things will go wrong in any given situation, if you give them a chance...It is most often cited as "Whatever can go wrong, will go wrong" (or, alternately, "Whatever can go wrong will go wrong, and at the worst possible time, in the worst possible way”)...The saying is sometimes referred to as Sod's law or Finagle's law which can also be rendered as "Anything that can go wrong, will—at the worst possible moment". (adapted from Wikipedia)

Well Murphy’s Law is pretty pessimistic and ominous, but I guess for those of us who are old enough to have lived through some of life’s up’s and down’s (and Murphy’s Law would probably say they’re mostly downs), then the adage is not only meaningful, but also a cautionary tale for how we conduct ourselves.

No, It’s not about being paranoid or schizoid or any of those things.

But probably more a big “WATCH OUT!” or “KEEP YOUR EYES OPEN!” sign plastered along the bumpy, curvy road of life.

One of my old pals has a spin of Murphy’s Law (although I don’t think he see it quite that way) that goes like this: “Man plans and G-d laughs.”

As a manager, I see Murphy’s Law as part of good program and project management. It’s about planning, planning, and more planning (sustained and determined), with plenty of risk management built in as you execute and deliver to the customer on behalf of the enterprise.

But even with planning and risk management, you can never cover every eventuality. What you can do is try to prevent or avoid certain risks, mitigate others, and accept the ones you can’t avoid or mitigate. Pretty much, simple as that.

User-centric EA is a process for the enterprise to plan and manage risk—all those inherent in Murphy’s Law. EA does this by formulating, documenting and communicating where the organization is at, where it is headed, and how it is going to try and get there. Furher, it vets these plans with leaderhip and subject matter experts, builds consensus, and drives positive, incremental change. EA helps the organization adapt to changes internally and externally. EA is a bulwark against the law of “anything that can go wrong, will.”
Share/Save/Bookmark

September 1, 2007

My Dear Technology and Enterprise Architecture

Oh how dear is my technology?

The Wall Street Journal, 1-2 September 2007, wrote about a dying woman and her last words to her daughters:

“In the past four years, I have replayed that moment again and again. The beeping of machines. The manic bustle of nurses. Doctors spouting terms like ‘lung failure.’ And, ultimately, my mom toiling to draw a breath…so that she could ask that my sister, Lizzie, and I safeguard her eBay reputation.” !!!!!

There’s more…

“Mom radiated fear throughout her illness…once, when my sister brought to my mom an old photo album, my mom told her she didn’t want to look through it. And then Mom slid her Mac unto her lap and logged on to eBay.”

The daughter’s conclusion…

“She was dying. But with her iMac and wireless internet connection, she found life.”

I am sure that this article is as shocking to many of you as it was to me. Not that we can or should judge anyone. Hopefully, we will never be in this lady’s shoes. But it does seem bizarre that even when the mother is deathly sick, she is neither interested in her faith, her family, her memories, or her good deeds—the things that are usually the treasures of most of us—but rather is apparently all consumed by her computer, her wireless connection, and her website.

As a professional in EA, I have frequently encountered people at work at their love affair with their pet technologies. They saw it in a trade mag; got this “unbelievable” brief or slick brochure from ABC company; viewed this demo at a trade show; and now they “gotta gotta have it!”

In a sense, adults are just big children. They have to have their toys. They won’t stop whining and bellowing until they get it. And once they get it, they play with it for a short time, and then it goes into the corner to collect dust.

This is exactly what User-centric EA and IT governance is supposed to protect the enterprise against. EA and capital planning & investment control are designed to help filter out the technology winners from the losers, and those that align with the needs and strategies of the organization from those that are merely toys. There are a lot of whiners and bellowing customers out there, buying them their toys is not user-centric, but just foolish and a waste of valuable corporate investment dollars.


Share/Save/Bookmark

August 29, 2007

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.


Share/Save/Bookmark