Showing posts with label Systems Development Life Cycle. Show all posts
Showing posts with label Systems Development Life Cycle. 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

October 6, 2017

People, Process, and Technology Lifecycles

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

June 5, 2012

SDLC On Target

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 tailoring SDLC 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)

Share/Save/Bookmark

May 22, 2010

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.


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 30, 2007

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.


Share/Save/Bookmark

October 21, 2007

Circumventing the CIO—What’s the Harm?

One of the most difficult challenges we face as enterprise architects is when end-users don’t ask permission, but instead ask forgiveness.

The typical scenario is that a division or unit or group of end-users decides to go out and purchase some new IT widget, gadget, or system without going through the CIO shop. (I know this shouldn’t happen if the CIO controls the IT funding, but even then someone always finds some money squirreled away and decides to use it for something they weren’t supposed to or in some cases even bypasses the money channels altogether, getting a freebie from a eager vendor looking to build or test some new capabilities to sell later to other customers).

Well, where’s the harm?

Oh my G-d, where should I start…

Innovation from the field and operators is great, but bypassing the CIO shop circumvents the structured processes and good governance that is in place to ensure projects succeed. Without these mechanisms, IT project can be at tremendous risk:

  1. Business Case—Without a business case, the justification for the IT project was never made, return on investment not calculated, alternatives not considered, and the best course ahead not properly laid.
  2. Investment Review Board—Without IRB vetting, the senior-level sponsorship has not been solidified, the project has not been authorized, and its priority has not been set with respect to other, maybe more critical, projects that the enterprise needs; further, the project may not have adequate life cycle funding; additionally, the project is likely not being ongoingly monitored and managed by leadership and enterprise subject matter experts for cost, schedule, and performance.
  3. Enterprise Architecture Review—Without an EA technical review, the IT project may align with the target architecture and transition plan, may not be interoperable with other systems, may not meet enterprise technical standards, may overload or be incompatible with existing infrastructure, may be duplicative of other investments, may not be the best or most cost-effective technical solution, may not meet various legal, regulatory, and other compliance requirements.
  4. System Development Life Cycle—Without following a defined, repeatable, and measureable SDLC process, the project risks failure by not having adequate and documented planning and requirements, design, development, testing, implementation, training, operation and maintenance, and disposition.
  5. Project Management Plan—Without a project management plan, projects are at risks for being mismanaged, having cost-overruns, schedule delays, and quality problems.
  6. IT Security Plan—Without an IT security plan, the project is at risk in terms of the confidentiality, integrity, availability, and privacy of the information.

No question, from an end-users perspective, there are quite a few hurdles to go through in implementing a new IT project. An if we’re honest with ourselves, the process can be onerous. Therefore, the CIO and his staff needs to work to streamline the processes, integrate them, provide the users with job aids and excellent customer support. Additionally, there should be a quick pass process for getting those “emergency” (must have now) projects through quickly (although not any less comprehensively).

The key is to balance the needs of the enterprise (ensuring mission execution and sound stewardship of enterprise resources), end-users (supporting innovation and operators ability to do their jobs successfully and safely), and customers or citizens (bringing new products or services to market quickly, reliably, and at high quality levels). To do this we have to balance the necessary processes and governance to ensure IT projects’ success with the imperative to foster innovation and deliver quality and speedily to market.

So as an enterprise architect, what do you do when a end-user asks forgiveness, instead of permission?


Share/Save/Bookmark

September 24, 2007

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.


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