Showing posts with label PMBOK. Show all posts
Showing posts with label PMBOK. Show all posts

November 11, 2008

Improving Project Management and The Total CIO

IT projects are notorious for coming in late, over cost, and not meeting the customer’s needs.

CIO.com has an excellent article on ways to improve project management in an article entitled, “When Failure is Not an Option,” by Meredith Levinson (3 July 2008).

For organizations, good project management is a critical success factor!

“Project management is the number-one success factor for getting anything done in the organization. A firm’s ability to execute its strategy lies with its ability to manage projects,” according to Sam Lawler, the director of GlassHouse Technologies’ project management practice.

Yet, for years, organizations have faulted CIOs and IT departments with failed IT projects. As recently as 2004, a study by The Standish Group found that only 29% of IT projects “were completed on time, on budget, and with all features and functions originally specified.”

Project management methodologies work when business and IT work together as a team.

There are various methodologies being employed to try to improve project’s success, such as PMBOK and ITIL. However, IT projects’ success depends on IT and business people working together to achieve results; if this partnership and collaboration doesn’t happen, then no PM framework will bring us the project success we desire. Our organization’s business people are critical to ensuring project success—they develop the business case, identify requirements/functional specifications, realign and improve business processes, and test technical solutions to ensure they meet mission and business needs.

No longer is it about tossing the proverbial hot potato to IT and then pointing fingers and assigning blame when something doesn’t work right. Instead, the business and IT people are on the same team, sharing accountability, and working toward the success of the project and the enterprise.

Performance measurement is a must:

Improved project management needs to be accompanied by measurement of project success and reporting on these to executive management. We can’t manage what we don’t measure. And we need transparency to senior management to ensure that everyone—business and IT—have “skin in the game.”

Further, there are trade-offs in project management between cost, schedule, and scope/performance. Changing one affects the others, so we need to manage projects harmoniously in this triad. If for example, a project is delayed or costs more, but delivers on added functionality requested by the business, then the project can still be a success. At the end of the project, success is defined by the business!
Share/Save/Bookmark

May 23, 2008

Frameworks and Enterprise Architecture

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

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

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

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

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

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

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

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

Here’s an example using a few of these:

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

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

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

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

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


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

August 12, 2007

Enterprise Architecture: Program or Project?

Enterprise Architecture is a program with many phases and projects.

Several times in my career, I have been brought in to develop an enterprise architecture for an organization, and just about every time, the boss has asked how long will it take, when will it be done, or some other similar version to time-bind the effort.

However, for those of us who are practitioners in the field of EA, we know resolutely the answer is that EA is never done.

Legally, EA is mandated by the Information Technology Management Reform Act (a.k.a. the Clinger-Cohen Act). As such, it is not a one-time event, but an ongoing requirement, and thus an established program in every department of the federal government.

But more than that, EA defines the current, target, and transition plans for an organization. And by definition, a current and target are just snapshots in time, which are in essence outdated a moment after you publish (just like when you drive a new car off the dealer lot and it immediately becomes “used.”) That is, an organization, its business and technology, are constantly evolving and in a state of flux, responding to internal and external factors (such as new mission challenges, business opportunities, congressional or executive mandates, changing customer expectations, new technologies, and so on). So in an ever-evolving organization, the “current” state does not stay current, and the “target” does not stay current (up to date). That is, unless you place these under “maintenance,” i.e. you refresh these on a periodic basis, and make course corrections along the way.

Further, developing and maintaining an EA for any organization is a challenging task, especially for a large and complex organization (like many in the federal government). As such, EA efforts need to be broken down into smaller projects to be successful. And these projects need to be clearly defined in terms of scope, schedule, and performance measures and managed for all project knowledge areas (reference: Project Management Book of Knowledge).

So the next time your boss asks you, “When will the EA be done?” I suggest you tell them: “The EA is a program with many phases and projects. Phase (#) is scheduled to roll out (date).”

Has this ever happened to you – that your boss asked you when the EA would be finished? What did you say/do?


Share/Save/Bookmark