Why Formalize Project Management – RTMI Baby!

RTMI - Repeatable, Trackable, Measureable, Improvable

We need to ask the question, “WHY do we need project management?” Moree specifically, “Why do we need to formalize it?” We get the job done, don’t we? Nights, weekends, overtime, “the beatings will continue until the moral improves” as Blackbeard the pirate was fond of saying. We do what it takes. So, why formalize project management?

Let’s be real. We seem to get projects finished. It may not always be pretty. We may burn out a few people. And we may end up over-budget and behind schedule, but we do get them done. How can using processes help us?

By defining a process, we take the best of what we have done and do it again. If we never document what we have done, we have a hard time repeating it. We have a hard time transferring the job to someone else. If the person who knows the method to accomplish some task gets sick, leaves the company or worse, goes on vacation, how will we finish the work?

Processes make what we do:

  • Repeatable
  • Trackable
  • Measurable
  • Improvable

For those in the know, this cycle is simply a restatement of Walter Shewart and Peter Demings’ Plan-Do-Check-Act quality improvement methodology.

Processes are Repeatable

 By documenting our processes, we see what we did before. We don’t have to reinvent the wheel each time we perform a similar function. We simply pull out the documented process, follow the steps and end up with the same or similar results.

Another benefit of documented processes is “institutional knowledge.” We transfer the knowledge of the best practices to others on our team. They don’t have to learn from scratch or from observing others. The steps are defined and refined to improve our productivity and effectiveness.

Documenting processes does not need to be complicated. For example, following the nine steps while building your project plan as defined in this manual saves you time. Yes, there is a learning curve and lower productivity while you learn the process, but the end result is repeatable actions saving time and delivering predictable results.

Processes are Trackable

 Once we can repeat processes, we can track them. We determine if we are doing the right step at the right time. We know if we deviate from the method defined. While there might be a reason to do so, we want to do so intentionally and not because we mistakenly took the wrong path.

For example, after a while, people learn the shortest or fastest path to get to work (well, more likely, to get home from work). They use the same path over and over because they know it works. The first time they took the route, they probably mapped it out using Google Maps or some other service, GPS, etc. Once they became familiar with the area, they may have learned shortcuts not originally given by the earlier process. They actively decide to take the shortcut. Had they not had the original route, they wouldn’t have known the shortcut was truly shorter. By tracking the original path, they knew when they deviated from it and how to improve it.

Processes are Measurable

 Once we define our repeatable process, we can track it. As we track it, we realize we have certain measurements which help us determine if the process is working or not.

Going back to our drive-home route example, we learn by leaving the office at 5:00 pm, we should be at the red light on 45th and Main Streets by 5:25 pm. If we are there earlier, we’re doing great. If we don’t reach the intersection until 5:45 pm, we know we are running behind schedule.

Those measurements let us know how we are progressing and if the process is still working. If we discover a slightly different route which chops fifteen minutes out of the schedule and yet delivers the same results (quality, performance, outcome), we modify our process – the route we drive. By knowing the amount of time prior to the improvement and the new time after the improvement, we have a comparison for future performance measurement.

If the time begins to increase back to the original – others find the same route and it becomes jammed – we begin to look for improvements again. The measurements let us know how we are performing.

Processes are Improvable

 Just as we saw in the example under measurement, we were able to improve our method by finding a new route. Unless we can repeat what we have done through defining our processes, we cannot track, measure or improve them.

The key, therefore, is the very first step: eliminate the Wild-West approach of “just gitt’er dun,” by documenting the processes, tracking, measuring and improving.

Consequences of Process

 We defined the benefits of processes. Let’s be fair and understand some of their downsides.

1.  Implementing processes takes time, lowers productivity and adds bureaucracy and red-tape.

To document what we have been doing and creating processes is a lot of work – True. They slow people down – True. They create more paperwork – True. Processes hold people accountable and we know the responsible person when something goes wrong – True.

Well, all those are true and more – at least initially. There is a learning curve to anything new. Fact is, people are following a process now, whether it is documented or not. But in many cases, only they know the process. Therefore, if the person has to be replaced, the substituted person struggles and typically can’t keep up. Overall, the work slows down.

By defining the process, others learn or at least have some reference information to accomplish the tasks and in the proper sequence.

Additionally, we know who is responsible for doing what. We are not here to point fingers, but more to determine how to fix problems. Is it training? Does the person have the wrong authority? Are they physically capable or incapable of doing the job? We can pinpoint the problem and apply a solution.

2.  People hate being told what to do and don’t like change. They want the liberty to do it their own way. If the truth be told, processes are more liberating than confining. Rather than fretting over the next step, their decision-making capacity is spent on improvements, not reinventing the wheel. By making them a part of the process development or improvement, they become co-owners and more involved raising the quality of their work.

Conclusion

Process has its benefits and detractions.  Once it becomes part of the daily routine, we simply do it and stop noticing it, just as we stroll the same route to get a cup of coffee. Any change to the path causes consternation to many; a loss of productivity until the change becomes part of the regular course of business. By having a formal process, we can examine it for inefficiencies and fix them because they always exist.

Project management is not a singular process, but a complex interplay of processes and methods across multiple divisions and disciplines within the organization. Without process, without formalization, we cannot keep the lines of communications, work and results from becoming entangled. Following the RTMI discussed in this article, companies can reap the benefits of formal project management methodology while minimizing its disadvantages.

 

Copyright © 2014, David A. Zimmer, PMP  All Rights Reserved



IT Cube – Six Perspectives to Project Requirements

Gathering requirements for a project is critically important to the overall project success. Without proper requirements, detailed so they are attainable, a project manager’s ability to achieve project completion or stakeholders’ satisfaction is greatly diminished. Basically, he is shooting in the dark hoping he’ll hit something akin to the thoughts and expectations of the influential powers. For many organizations, requirements gathering is not a process but rather a race to implementation.

A company hired us to help them conduct proper technology selection for a strategic business application. At our first meeting with the client, we asked if requirements had been gathered concerning the new platform. They proudly produced a half-page, bulleted list of items the new system was to provide. We politely asked if that was it. No details. No lists of user needs, business tie-ins, strategic propositions, or customer service thoughts. Ten bullet items of “wants.”

Fortunately, and in anticipation since we had seen this before, we produced a document listing requirements and their descriptions we had accumulated over the years working with other clients. The ‘thud’ on the table startled the client a bit, but he was very excited we had something real from which to work, and more so, because he didn’t have to create the same list and description – the work was done!

What’s the PMBOK® Guide Say?

The Project Management Body of Knowledge (PMBOK® Guide ver. 4) states in Process 5.1 – Collect Requirements, “Collect Requirements is the process of defining and documenting stakeholders’ needs to meet the project objectives. The project’s success is directly influenced by the care taken in capturing and managing project and product requirements.” It goes on to describe the inputs, tools and techniques, and outputs of the process. Fundamentally, the discussion is accurate, but it leaves out the perspective of each stakeholder. While implicitly suggesting the six perspectives outlined in this article, explicitly and proactively viewing each perspective provides clearer and more complete requirements for any project.

What’s the BABOK® Guide Say?

We turned to the Business Analysis Body of Knowledge (BABOK® Guide ver. 1.6) to see if they included discussion of the six perspectives. Again, they discussed the tools and techniques with a mention of various stakeholders. Once again, we want to be more explicitly clear of the viewpoints.

What is IT CubeTM?

The IT Cube is a conceptual method of ensuring all aspects of a project, technology selection, or decision is adequately considered.

Imagine a project as a sphere. Place that sphere inside a six equally-sided box or 3D cube. Each side is transparent so the sphere is easily seen. As you view the sphere through each of the clear sides, you see a different aspect of the ball. From one perspective, the ball may appear blue. From another, peach. From a third, dimpled and so on until you have looked through all six panels. Each view portrays a different “idea” of the sphere.

The same holds true as you focus on project requirements, product definition, service features, etc. By explicitly considering each angle of the project, different requirements emerge. Some may be in direct conflict or compliment requirements from another view. Unless studied in this manner, those requirement clashes may not emerge.

The Six Perspectives

Six perspectives for any project exist. They are:

1. The “Technician”

2. “Technical” Management

3. Business Management and Executives

4. The User or Customer

5. Analysts and Pundits

6. Vendors

Each has a unique view of the project and a vested interest in its outcome, with a possible exception of the Analysts and Pundits, although, their opinions can influence decisions.

Let’s define each and understand their needs.

Panel One: The “Technician”

Our background is IT and therefore we think in terms of business application software and hardware infrastructure. Not all projects are IT focused, consequently, we want to broaden our discussion here to be more generic. The term “technician” has more to do with the people implementing the project. For example, in construction projects, the technician would be the laborer whose skills build. In marketing projects, the marketing person developing plans becomes the technician. The chemist and research scientist would be the technicians in pharmaceutical developments. And so forth.

The questions a technician might ask concerning the project and therefore, their requirements will be more of a technical nature. For example, they might ask
•“How will the new system impact the current infrastructure?”
•“Is this an additional item to our list of services to the organization?”
•“Do I have to learn new information or will my current knowledge be sufficient?”
•“If new knowledge is needed, will I be trained?”
•“Are we doing away with something else?”

As shown, the questions concern the day-to-day operations. Support questions might come to mind once the new “technology” is selected, especially if the technician will be supporting others. In the case of the research scientist, it might be “what support will I get” and so forth.

Therefore, gathering requirements from this group of people is important because they will be the ones implementing the solution and possibly supporting it. As a result, day-to-day operations success after implementation depends on the buy-in and commitment of this group of individuals.

Panel 2: “Technical” Management

“Technical” management concerns are different. This group of people is the managers of the “technicians.” The management must answer to two groups: Business Management and Technicians. Essentially, their requirements include meeting the business ROI, TCO and SLAs while at the same time, supporting the needs of the technicians to operate the technology efficiently.

Their questions may be:
•“How will this technology meet the organizational ROI and TCO requirements?”
•“Will the new system help me meet the SLAs better or more easily?”
•“Will it make the technicians’ work easier so we can provide other services?”
•“Are there other methods of meeting the needs expressed or do we already have systems in place so we don’t need to add another?”
•“Will this meet the business initiatives and align with the strategic plan?”

The questions follow a more business line of thinking, but still with a technical orientation.

Panel 3: Business Management and Executives

Business Management and Executives look at the profit and loss propositions of any new implementation. Their goal is to meet their goals as stated in the strategic plan, along with their own initiatives. Each project should move them further along those plans.

This group’s questions might be:
•“How will this technology align with the strategic plan?”
•“I don’t care about the technology so much. I’m more concerned with it meeting my goals, objectives and initiatives.”
•“How will this project move me further along my initiatives?”
•“How will this implementation make us more revenue or profit?”
•“What is the cost?”
•“What is the priority of the project compared to other needs?”
•“Does the return outweigh the cost or the cultural impact we will incur?”

Notice the questions center around financials and investments of money with overtones of impact on the company environment.

Panel 4: The User or Customer

The users or customers employ the project’s outcome. Their needs determine the usefulness of the project’s result and its use. Whether the project results in a building, a new medicine, a software package to automate tasks, or whatever, the acid test of any successful project is its users’ acceptance. Involving the customer during requirements gathering is essential in the final analysis.

Customers or users may ask:
•“Why do we need something new or better?”
•“How will this benefit me?”
•“Will this help me do my work better, faster, or with less people?”
•“Does it eliminate the frustration I am feeling with the current method or system?”
•“I need this item or this feature. Will the new system do that for me?”

The questions center on their particular set of tasks or duties. They are more tactical in nature, getting down to the day-to-day operations of the business.

Panel 5: Analysts and Pundits

Industry Analysts provide valuable information from a different perspective. They may rate the technology vendor’s stability and longevity – an important aspect for large investments or long term usage. They review the feature set against other offerings of similar ilk and point up the highlights and lowlights of the offering. They present ideas and opinions based on customer surveys and questionnaires. In many cases, they present a more objective viewpoint.

This group of people might wonder:
•“How financially stable is this vendor?”
•“What is their customer support structure? Do they support both large and small customers?”
•“What is the vendor’s current customer base?”
•“How does their product or service feature set stack up to the competition’s?”
•“Do they support just a niche market or do they serve a more general audience?”
•“Do they meet the expressed needs of customers according to our surveys and research?”
•“What advice can I tell my customers about this product or service? What opinions will they find valuable?”

Panel 6: Vendors

Vendors are the ones producing the product or service you want to buy. In many cases, the product or service you are considering will meet some, but not all of your needs or desires. Vendors want to know what your requirements are so they can help you understand which ones they support and how closely. For the ones they don’t support, they will find creative ways to support them.

Vendors will ask:
•“What is your ultimate end result you want to achieve so we can show you how we can help you get there?”
•Why do you think you need that feature or function?”
•“In order for us to be able to support your need, you need to do X, Y and Z. Is that OK?”
•“If this project is successful, what quantity of products or services will you purchase?”
•“How can we aid in making your project successful?”

The vendor is looking to sell products and services. They might place requirements on your project to make it better.

Conclusion

While all the perspective descriptions may not be directly valid for every project, the different angles should be addressed. For example, an internal project that doesn’t use outside vendor offerings still has internal vendors and customers. Those perspectives must be considered and documented. If no requirements come from a particular perspective, then we should explicitly note that fact.

IT Cube is a conceptual model to follow to ensure all stakeholder needs are considered. Missing one side of the cube will leave an opening dumping the project’s success onto the floor.

Tell Us What You Think

We invite you to comment on this article. Does the concept make sense to you? Are there additional sides we should consider? Is it a useful model for eliciting requirements and practical enough to ensure full consideration of stakeholders’ needs? Let us know what you think by leaving a comment.

IT Cube is a trademark of American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective trademark holder.

Copyright © 2009, David A. Zimmer, PMP All Rights Reserved



Utility Services: The Funnel For Driving IT Request Fulfillment Efficiencies and Savings To The Bottom Line

Utility Services is a governance model of ensuring all solutions implemented within an IT organization meet the traditional criteria of customer sign-off requirements, solution design and testing, and release into the environment. It establishes and enforces necessary customer communication checkpoints via a series of documentable and repeatable processes and procedures. It ensures IT goals align with business needs and initiatives through a consolidated resource management interface to manage work-loads and enable resource forecasting. And finally, it streamlines standard requests by automating approvals, traceable milestones, requester communication and hand-offs as appropriate.

Why Utility Services?

The big question still remains. Why implement Utility Services? You already seem to be getting the job done. Sure, your people are overworked and under-appreciated, but they still show up for work each day, don’t they? Why rock the boat, change the way of doing things and suffer through the cultural shock of more efficient operations?

For those companies where we helped them implement Utility Services, here is what they report:

  • Utility Services enables organizations both small and large to best utilize their money and people.
  • Utility Services reinforces ITIL good practices by building the underlying philosophy into the systems that IT departments live by.
  • Utility Services can be implemented in a relatively short period of time, enabling “quick wins” for management and IT workforce stakeholders.
  • Utility Services continues to evolve with your IT department so it becomes more transparent and easier to adapt to business initiatives.
  • Utility Services takes the mystery out of implementation status.
  • Utility Services helps align the infrastructure with business goals, and escalates issues before they become problems.
  • Utility Services enables purchasing departments to more accurately forecast spending schedules and empowers them to negotiate better pricing and support from vendors, be it hardware or services.
  • Utility Services allows more effective time management and prioritization of your IT department’s time and money.

Conclusion

Fulfilling business requests takes up much of IT’s daily time. Inefficient methodologies erode the very infrastructure and people required to keep the business going. Untraceable changes and updates introduce instability into an already overly complex and vital system to the business. Personal agendas and priorities drive the changes without considering the benefit or detriment to the business. IT staff, desiring to do a good job and meet the needs, work at full speed but seem to fall short at the end of the day.

Utility Services takes the inefficiencies, the uncertainties, the liabilities and the insecurities out of IT Request Fulfillment. By funneling requests through an automated and organized process, duplication of effort is eliminated, overspending on materials is slashed, workloads can be adjusted to align with business needs, personal agendas can be removed and priorities are established to truly meet the business’ highest priorities for the greatest gain.

We have seen companies transformed saving millions of dollar annually on purchases alone. IT efficiency increased dramatically and the stability of the infrastructure reached desired service levels without significantly increasing costs. The implementation and definition of Utility Services takes a chaotic methodology, structures it and drives it for the maximum utility to the business.

Copyrighted by American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective copyright holders.



PMO, CobiT, ITIL – Alphabet Soup for Strategic Information Technology Services

When I was younger, I ate alphabet soup. I stirred the broth and watched the letters as they swirled around. Many times, simple words rose to the top. As I learned to read, I would exclaim the new found word. Little did I know that as I matured, letters would continue to swirl and new found words and acronyms would continue to form. The IT broth has been stirred. While not necessarily new, PMO, CobiT and ITIL seem to be rising to the top of the bowl in the IT industry.

Fig. 1: Three Avenues To Better IT Infrastructure Services

We have three, and more, efforts trying to solve the IT dilemma – providing quality services in an ever changing environment while aligning with business requirements and drivers. We need to understand these three – PMO, ITIL and CobiT, and how they integrate to provide the best IT Infrastructure services. The questions we need to answer are

  • how will each effort support our need of aligning business requirements and IT infrastructure;
  •  why do we need three efforts instead of consolidating them into one;
  •  how do they integrate, compliment and overlap; and
  •  how do we use them to our benefit?

This article introduces a series of articles describing the various components and how they integrate forming a comprehensive governance of IT within your organization. Each component is not mutually exclusive of the others; in fact, they are greatly complementary. The overlap provides us the opportunities to better understand IT relationship to and support of the business requirements for your organization. IT is no longer a cost center draining the organization of precious resources, but becomes a strategic weapon supporting the business in its efforts to out maneuver the competition and branch into new markets. Although we have often heard that statement, the use of CobiT and ITIL provides the mean to make it true.

By necessity, we will only introduce the various topics at a very high level, saving the details for the later articles in the series. We have purposely simplified these complex areas in order to introduce them, but we will add the details later. So, if you are an expert in these areas already, bare with us as we bring the rest of the readership up-to-speed. We discuss three elephants of understanding, so we need to only chew what we are able. If you are a neophyte, welcome and fasten your seatbelts – turbulence ahead.

Let’s start our journey by understanding briefly the five components within the system as shown in Figure 2: Business requirements and drivers, IT/IS Systems, Services and Infrastructure, Project Management Office (PMO), Information Technologies Infrastructure Library (ITIL) and Control OBjectives for Information and related Technologies (CobiT).

Fig. 2: PMO, CobiT, ITIL Integration

Business Requirements and Drivers

The business requirements and drivers determine the direction of the organization. The IT infrastructure is expected to support that direction. In many cases, the business requirements are not adequately documented or communicated to the IT personnel to gain such support. Additionally, the requirements speak a different language than the IT department.

The CIO and IT Management translate between the business needs and the IT infrastructure reality. Without a standard approach to such translation, it may not be as accurate as needed. The results: a mismatch between the infrastructure and the needs, festering frustrations and creating divisions. Unfortunately, this incomplete or inconsistent translation is not seen until well into the process of implementation or even during actual use. The cost of fixing such a dilemma becomes exorbitant. Industry studies show that over 66% of IT-based projects fail!

By using a standard approach with appropriate metrics and life-cycle planning, we begin to mate the business requirements and IT infrastructure realities. Within the standard approach, we add auditing ability to give us the checks-n-balances needed to assure we obtain the proper return on investments.

IT/IS Systems, Infrastructures – Realities

The IT infrastructure and systems support the ongoing business. It meets the needs for the users’ day-to-day operations and any new development work. The infrastructure includes desktop and server machines, networks, storage, and software used to meet business demands. Software includes the general purpose programs such as word processors, spreadsheet and presentation software, email, etc. It also includes specialty software such as CAD/CAM, publishing, accounting, CRM, ERP, etc.

The infrastructure becomes a reality based upon the business requirements understanding and established through some type of project procedure. The goal is to evolve the infrastructure as the business requirements change and mold to market conditions. One problem that exists is the rapidity of requirements changing versus the speed of evolution of the IT infrastructure. Add to that disparity the non-standard method of translating business requirements into infrastructure reality and the lack of auditable metrics, we begin to see the quandary we possess.

PMO – Project Management Office

The Project Management Office is a virtual organization within your organization that is populated with people who manage projects. Projects translate business requirements into IT infrastructure realities to be used for the business evolution. The PMO dispatches a project manager to manage a project which implements the desired solution. In a perfect world, the end result would match the business requirements. Using best practices and standard procedures, the project manager guides the project to the desired results with full acceptance from the users and receives standing ovations and a hero’s welcome. Right?!

The Project Management industry has done an admirable job in defining the process from requirements to reality, but by their very definition, their responsibility ends at project completion. A project is a temporary endeavor to produce a unique product or service (PMBOK). The definition defines a beginning and end to a project. Once the project is complete, there is no ongoing feedback loop to evaluate the results of the project. The project manager’s responsibility is complete.

Ongoing monitoring of the project’s results must occur in light of the business requirements that drove the project in the first place. Are the results still in line with the business requirements? Did the requirements change? Did the market factors that defined the requirements change? If so, should we change the infrastructure? What is the process? How do we determine the financial impact? These and many more questions start flooding one’s mind.

ITIL – Information Technologies Infrastructure Library

Enter ITIL – Information Technologies Infrastructure Library. ITIL is a collection of best practices that help move business requirements through the project stage, into the reality or implementation stage and provides the life-cycle feedback necessary to keep the infrastructure aligned with those requirements. Driven from the technical community to better understand requirements from its primary customers – the business user and management, ITIL standardizes the language so business requirements translate into technical terms properly, or at least, consistently.

ITIL is not a “how’s to” guide to better IT Service Management. It is a framework of practices to measure, validate, and report against the business needs and requirements. It shows how the IT infrastructure works together to meet the business needs. In other words, it lets the business dictate the implementation of IT services and infrastructure rather than letting the latest IT advance push the business to its adoption. More importantly, it uses a common vocabulary to promote synergy between the business drivers and IT implementations. It becomes a collection of documents outlining the process from requirements to implementation and back to requirements.

Two versions dominate the ITIL landscape today: version 2 and version 3. Version 3 has been ratified and is being introduced to organizations now. Version 3 is an evolution of version 2.

Version 2 focused on process development. It defines the necessary best practices to create IT realities from business requirements. Using common vocabulary, business users could articulate their needs at the beginning of the implementation process and then measure the outcomes once the IT infrastructure was deployed. Version 2 looked at specific discrete areas and disciplines, so it was seen as “silo focused.” Version 3 takes those best practices, now that they are defined in Version 2, and applies them in a holistic view of the organization. It provides a feedback loop using the common vocabulary and best practices into the requirements process giving us a tangible, business life-cycle from requirements identification and definition to implementation to acceptance and back into the requirements phase again. It provides the step-wise refinement necessary in IT evolution for constant business support.

In Figure 2 above, we can see that ITIL underlies the first three components discussed: Business Requirements, PMO and IT Infrastructure and Services (the blue ellipse). As you can see from the life-cycle arrows, it starts before a project initiates, continues during the PMO’s involvement and lasts long after the project manager has gone home.

The PMO uses ITIL’s framework to ensure proper monitoring and adjustments necessary to align the project results with the business requirements. The life-cycle arrows show the feedback loop going back into the PMO resulting in infrastructure changes and so on. The PMO does not obviate the need for ITIL, nor does ITIL displace the PMO. The PMO provides the methodology for a systematic step formation for managing projects. ITIL provides the components projects must supply for future monitoring of the projects’ outcomes.

CobiT – Control OBjectives for Information and related Technologies

Control OBjectives for Information and related Technologies (CobiT) comes from the audit industry. From the fallout of Enron and other notable large organizations’ scandals, we see the rise of legislation and regulations requiring accountability in all facets of companies. Because of regulations such as Sarbanes-Oxley (SOX), every aspect of business comes under the microscope of the auditors. IT is no exception. CobiT is a framework of good practices that places audit points into IT services so that we can determine financial accountability. It goes beyond the financial aspect and compliments the tenets espoused in ITIL. So while ITIL documents the life-cycle of IT infrastructure and services, CobiT keeps our attention to the audit criteria and gives us the checkpoints needed to assure compliance. CobiT defines 34 audit points that span ITIL’s domain – before project initiation and lasts long after the project is over. It provides a life-cycle as ITIL does, but it focuses more on a direct correlation between business requirements and IT infrastructure realities financially. It underpins the PMO with audit points.

Conclusion

PMO, ITIL, CobiT – three acronyms formed by the swirling IT broth. Each focuses on different aspects of the IT business. Each hope to convert business requirements into IT infrastructure that support the business needs. Each provides a different perspective on the road from business requirements to IT infrastructure realities. But they are not mutually exclusive. In fact, we see each underpinning the others for a mutual benefit. The PMO uses ITIL and CobiT so the project results enter a life-cycle that is accountable and tractable. ITIL uses the PMO to establish the life-cycle necessary for feedback and monitoring of the infrastructure to the benefit of the organization. CobiT puts into place the audit points keeping our business on course and out of hot water. It uses ITIL to document the audit process and the PMO to implement the audit points. Each leverages the strength of the other.

This article is just a cursory introduction to the deeper aspects of each component. In subsequent articles, we will explore the roles of the PMO, ITIL and CobiT in the business requirements-to-IT infrastructure within an organization and specific integration of these important frameworks.

 

Copyrighted by American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective copyright holders.