About American Eagle Group American Eagle Group Services American Eagle Group Method of Work American Eagle Group Articles American Eagle Group Affiliations Contact American Eagle Group

Need training in proper project management practices? Want to pass the PMP exam on the first try? We've shown companies how to lower defects rates by 25% and have a 100% pass rate on the PMP exam. If you need the best, you need American Eagle Group. Contact us now for your project management training.

Thursday, August 10, 2017

This blog is moving....

David A. Zimmer
David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

Thank you for visiting. The content of this blog is moving to a new location. Location will be announced shortly.

Tuesday, October 07, 2014

Why Formalize Project Management - RTMI Baby!

David A. Zimmer
David A. Zimmer, PMP
Chief Project Professor
American Eagle Group

We need to ask the question, “WHY do we need project management?” More 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.


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.

Tuesday, June 30, 2009

IT Cube - Six Perspectives to Project Requirements

David A. Zimmer
David A. Zimmer, PMP
Chief Project Professor
American Eagle Group
PrintListen Now

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® Say?

The Project Management Body of Knowledge (PMBOK® 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® Say?

We turned to the Business Analysis Body of Knowledge (BABOK® 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 Cube?

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.


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.

To learn more about my kick-butt Project Management 5-day boot camp or excellently rated MS Project seminars, shoot me an email or call +1/215-491-2544. Thousands have reaped the benefits of more project success from this valuable training.

IT Cube© is copyrighted by American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective copyright holders.

Monday, December 15, 2008

Project Management and ITIL for UC: Recipe for Sanity

David A. ZimmerPrint

Recently, I spoke with my old partner of the Unified-View, Art Rosenberg, about the recent press release by Orange concerning UC Hosting services. In particular, they announced their support for ITIL (IT Infrastructure Libraries) practices in order to best support their customers.

Since I last worked with Art in 2002 or 2003 timeframe, I have diverted into another path of consulting: project management and IT service management. These two areas answer many of the questions Art and I raised several years ago in search of the migration strategies for IT managers as they planned their UC implementations.

We wanted to know what methodology people would follow to plan UC projects while at the same time maintaining current technology so the business did not grind to a halt. We needed to know how individual users would determine which features and functions would best benefit them in doing their jobs better. We knew one size does not fit all. How can the telcom/IT managers align with both business initiatives and end user needs or would they simply cobble something together and dub it UC? Once in place, how would UC continue to evolve seeing it has so many moving parts with new technology and releases coming out rapidly while supporting SLAs and stability requirements?

My Evolutionary Process – Part 1

After twenty-five years of managing small to large technology projects, I learned there was formal training needed in project management. While for many, formal education was an obvious opportunity, I always felt, as many do, project management is simply learned by being around other people who managed projects and mimic them. I learned within the first session of my education, I was wrong. Now, I am not only formally trained, but I am certified as a Project Management Professional.

Since 2004, I have trained thousands in the art and science of project management with great success in turning projects within companies around simply by instituting a few simple processes.

My Evolutionary Process – Part 2

Similarly, I never realized formal industry standards existed for day-to-day operations of IT systems until I ran into the ITIL framework. I simply thought fixing fires and trying to predict future flare-ups was the norm. (Sadly, it is, but that can change with proper methodologies.) I am certified in ITIL version 2 and ITIL version 3 fundamentals.

In speaking with Art about UC implementation, I realized a broader audience would benefit from our discussion. Because of the nature of UC, its fluidity, variance of definition by company and user-base, and rapid advancements, project management and ITIL concepts and processes are key to successful deployment and upkeep of the system.

The Changing PMO

The PMO or Project Management Office is the focal point for project management governance and oversight. It establishes the guidelines and standards to be followed. Typically the PMO focus is on projects only. They have not been concerned with day-to-day operations.

For many companies, the PMO originated from the need to manage IT projects more successfully. Industry studies report close to 75% of IT projects fail. The PMO was implemented to increase the success rate. For those companies who have gone the certification route through the Project Management Institute (www.pmi.org) and trained their project managers, studies report a 70% success rate instead.

The success of the PMO governance and guidance of projects has lead many to believe that daily operations would benefit from similar oversight. As a result, the PMO has to morph into an organization supporting two industry standards. Traditional project management methodology does not support operations.

Additionally, the experience set of the two domains are quite different. For example, projects are a specific scope of work defined by begin and end dates, and the resulting product or service transitions into operations.

Operations, however, is ongoing, so they have no end dates but must smoothly transition new functionality and supporting infrastructure without any impact to the business.

What’s To Come

Here is a bullet list of topics to be covered in this series of articles:

  • An overview of PMO functionality,
  • Determining the need for UC (It’s not just IT management!),
  • Proper project management methodologies,
  • ITIL practices as they pertain to UC – both version 2 and version 3,
  • Comparison of Project Management and ITIL methodologies,
  • UC planning and implementation strategies,
  • UC lifecycle – evolutionary definition, evaluation, implementation and support of business needs as experience dictates and business drivers change (mobility, device upgrades, new technology, regulations and legislations compliance, competitive needs, social impacts, etc.),
  • Ongoing enhancements and support of the UC infrastructure,
  • And more.
I will reference practical experience from my past, but I would like to showcase others’ experiences also. Tell me how you handle your daily operations, any experience you’ve had with ITIL or project management practices, sticky points you’d like an opinion on, etc. You can reach me at info@ameagle.com or www.ameagle.com.

Copyright (c) American Eagle Group. Unauthorized use is strictly prohibited. Comment contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by American Eagle Group. American Eagle Group reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of American Eagle Group is final.

Wednesday, March 05, 2008

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

David A. ZimmerPrint

You know the drill. Someone from the business side makes a demand for new technology. Users have needs unmet because their applications stop working. Servers need to be updated, upgraded, maintained and babysat. The critical business application everyone takes for granted decided to take a vacation during the end of quarter sales blitz. And the auditors are breathing down your neck asking you to prove the value of your existence. Meanwhile, your number one lead technician is sunning himself on the beach somewhere without cell phone coverage.

Your Average Day

Just a normal day in the life of the IT manager and CIO. But, we can handle it – we’ve got enough fire-fighting equipment in place and hours in the day to keep everything down to a low roar. Then, the CFO calls your network administrator directly to ask for an upgrade to the fiber switches and more secure firewalls. “Not a problem,” comes the reply. The VP of Sales is pushing for a record-breaking year and needs more terabytes on the sales processing system. He hall-tackles the lead database administrator to discuss the possibility of adding space by the end of the week.
In the day-to-day operations of the IT infrastructure, we must meet the demands of the business as quickly as possible and maintain stability to the environment. While at one point we might have developed some system to handle requests in an orderly manner, the heat of the moment seems to win out and we bypass our own methods because of emergencies. As a result, we settle into a routine of emergencies, headaches and many activities. In fact, dare I say, we feel comfortable in this mode. We equate busy-ness with productivity, esteem and accomplishment.
At the end of the day, we can look back and actually glory in the number of BlackBerry messages we smacked, meetings attended, phone calls fielded, and “things” crossed off the to-do list. As we lay our heads on the pillow at night after the fifteen hour day exhausted, we feel good because of all the forward progress, even if chaotic, we made.
The major problem with this mode of production is many customers don’t get served. Business units needing IT infrastructure updates done sooner decide to go on their own and create it themselves. Of course, once in place, the IT department must maintain it adding to their already overflowing plates. While the business got served through this method, the company suffers through duplication of effort, loss of purchasing power, disparate systems supporting similar functions, non-traceable changes to strategic systems and an unstable environment. In short, a train speeding down the track out of control and no Superman around to keep it from crashing.
Fulfilling the needs of the business is what the IT department does – that is their purpose. Support the business so the business can meet the needs and demands of its customers. If IT systems fail, the business fails its customers. Therefore, IT Request Fulfillments is a vitally important part to the business. Making it efficient and effective benefits all: the IT department, the business and the business customers.

What is Utility Services?

Utility Services takes IT fulfillment request and pushes them through a defined methodology that funnels requests through a “gatekeeper” without introducing a bottleneck to the speed of business. It puts sanity into the chaos, providing economy of scale through purchasing power, efficiencies in operations, and effectiveness in implementation. It preserves the holistic view of the overall system so changes can be tracked, monitored and maintained. Overall, the IT department gains through planned organization of changes, the business benefits through greater functionality and IT responsiveness plus stability of the IT environment and the business’ customers acquire a more secure sense of comfort from their supplier.
Utility Services is an independent workflow management system providing a single interface for IT requests – updates, upgrades, new functionality and the like. It leverages the good industry practices such as ITIL and reuses existing infrastructure for new applications, combines similar requests into a single work stream leveraging purchasing power for greater cost savings. Most importantly, it frees the IT department from the chaotic request processes of today so that they can be more responsive to the business requests, which seems almost counter-intuitive.
I hear you moan, “Oh great, more processes, more paperwork, more red-tape, more structure equals more pain to get anything done.” After years of helping companies develop and institute processes, we have learned at least one thing: Those companies that develop systematized methods, enforce their use and improve them rather than ignore them, progress further, sell more and increase profits and savings than those that do not. Some see increases in ranges of 20%, 50% and greater. Industry studies back up these claims.
Companies have greater insight into current and project capital spending, human resource allocations and requirements and more efficient day-to-day operations and successful projects.

A Governance Model To Meet Customer Needs

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.


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.

Monday, May 07, 2007

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

David A. ZimmerPrint

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.


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.

What Do You Think?

We are interested in your feedback. Do you feel that we have correctly characterized the interaction between PMO, ITIL and CobiT? Have you experienced the need for such frameworks within your organizations? Let us know by sending us an email to info@ameagle.com.

Sunday, December 10, 2006

Does Your Consultant Stack Up? Real Consultants vs. Wanna-Be's

David A. ZimmerPrint

The joke goes something like this: What's a Consultant? It's someone who can't get a real job and carries a briefcase!

Or, it's someone in transition, i.e., just laid off and in between jobs.
For those of us who are "real" consultants (and we will define that for you), the jokes are particularly bad because, as we endeavor to provide value-added services to our clients, our clients don't understand the difference between the Real McCoy and the Wannabe Clan.

As voting members of the Real McCoy’s, we will endeavor to de-mystify the differences and make it plain for those who are in search of an external expert.

The American Eagle Group has been an active member of the Independent Computer Consultants Association (ICCA) for over ten years. We have served as officers on the local Delaware Valley Chapter Board of Directors and served as the Vice President, President, Chairman, Treasurer, and now Secretary of the National Board of Directors in addition to serving as committee chairs and active participants in the discussion groups.

During our service to the ICCA, we have had frequent discussions - mostly heated - about the differences between a consultant, a contractor, and a wannabe. After all the hours of arguments and hot-air, we never really clearly defined the differences.

In a wonderfully written article written, "Are You a Real or Imitation Consultant," Aldonna Ambler, CMC, CSP of Hammonton, NJ which appeared in the Professional Speakers magazine from the National Speakers Association (NSA), dispersed the smoke around the wannabe consultant. She worked with a client who became shocked at the number of people who called themselves consultants, but were not. Ambler listed some characteristics of the Wannabe Clan (I list them here verbatim):

Characteristics of the Wannabe Clan
  • Expect business to just be handed to them;
  • Lack higher education in the topical expertise of their industry;
  • Think that they can learn enough content from a few seminars;
  • Do not walk the talk (apply the approach they are recommending / teaching)
  • Don't want to read any books, do any research or attend major conferences;
  • Had never learned techniques to objectively analyze a client's situation and needs;
  • Lack facilitation and project management skills;
  • Had never learned how to provide advice;
  • Lack creditability and have not demonstrated success; and
  • Lack depth and breadth of experience.

Is that a list or what? Does your "consultant" fit that list or the opposite list - the list that would describe a consultant? When evaluating a person's claim of being a consultant, do you have a list to measure them against or do you simply take their word for it?

So What Is A Consultant Anyway?
Certainly "consultant" has a certain air, panache, mystic, and finesse that contractor or wannabe do not. So of course, all of us who sell our services to clients want to be known as consultants. But that leaves you as the client in a lurch. How can you tell the difference between the Real McCoy and the Wannabe? If the Wannabe has no real consulting skills, they must have something that causes you to think they are a consultant. When we are hiring outside expertise, we want to get expertise and not a smoke-n-mirror show that leaves us drained of money, time, and emotion. We want return on our investment - true, tangible return.

In the article, Ambler answered with a list. We will add some ourselves (so we can't be accused of total plagiarism!). Ambler's list:

Characteristics of the Real Consultant
  • A real consultant is expected to bring appropriate credentials that result in expanded information and knowledge to their situation;
  • A real consultant is expected to bring objectivity to a situation;
  • A real consultant is expected to bring innovative thinking to a situation;
  • A real consultant is expected to bring facilitation skills to a situation; and
  • A real consultant is expected to adhere to a professional code of ethics.

Let's expand on these ideas so we understand what they really mean.

The consultant should have appropriate credentials. Credentials come in different forms: educational, designations, research, practical knowledge and experience, and previous successes (and failures - a real consultant will learn more from failure than successes so you don't experience those failures).

Does the self-proclaimed consultant have an advanced degree? Lest you think we are snobs, we do realize that years of experience can equate to formal education. In advanced degrees, students are not taught just more in-depth information, but a way of thinking and research. We at American Eagle Group possess advanced degrees and practical experience. We believe the lessons learned in research and thought-process during our advanced learning aided us to gained as much from our practical experience as we did.

Again, we believe there are many very intelligent and bright people who don't have the advanced degrees that can run circles around us. The difference is, "How can you tell?" An advanced degree in the topic helps you qualify the veracity of the claimant’s claim. Anyone can talk a good game.

Playing a good game is another thing altogether. The advanced degree shows the player went beyond the expected and pressed further into his/her expertise.

Aside from the formal education, what further study or research has the consultant performed? Did their education stop when they received their diploma or did they continue through independent study? The continuing education helps keep the consultant’s information fresh and current. Otherwise, it becomes stale very quickly.

And finally, is the consultant’s advice based upon information found elsewhere so you know it has a foundational basis or is the information simply being designed on the fly?

In the case of American Eagle Group, we possess advanced degrees in Computer Science and Project Management. We have been named to several Who’s Who lists, elected to several boards of various non-profit associations, published numerous articles and whitepapers, and contributed to several anthology books. And we will continue with those types of activities because they keep our information fresh and expands our experience base.

Is the consultant’s information biased? Do they recommend one solution over another because of their favorable experience or are they receiving financial restitution for recommending it? Is this the only product they represent? You, as a customer, want unbiased, non-directed information. You want information that helps you make informed decisions, ones that align with your goals and objectives, not the consultant’s. The consultant should be void of any allegiance to a particular vendor or supplier. The consultant should walk into a client’s site with a clear slate as to any products or services that would fit the customer’s needs.

This does not mean that the consultant should know or understand the values of various competing products or services. They should clearly know the available set of solutions for the client’s situation. But it is the needs analysis derived from discovery that should drive the consultant’s recommendation. While the consultant might have his/her favorite solution, he/she should willingly set that favoritism aside to recommend the solution best fit for the client’s needs.

If the consultant should receive any type of compensation if the client purchases the consultant’s recommendation, the consultant should clearly designate that such compensation may occur. Again, the consultant must not let the potential compensation mar or influence his/her recommendation.

In most cases, we have not recommended a solution to a client prior to completing the needs discovery process. Recently, though, the client had requested a proposal for project management consulting and training. In our proposal, we did recommend a specific solution and substantiated that solution with reasons. We clearly stated that we do not receive any type of remuneration for the purchase of the proposed solution and we carefully stated that the recommendation was based upon market factors and future direction, and not because of any bias toward that particular solution. During our meeting with the client, we re-iterated that point and the client supported our recommendation and was appreciative of the rationale behind the recommendation. They were also glad to know our recommendation was not based upon any financial gain to us.

Facilitation Skills
Facilitation is a fancy word for “make easy,” “make possible,” and “smooth the progress of.” We are not trying to diminish this important skill, but rather to help you understand a real consultant isn’t just technically savvy in his/her expertise, but knows other skills to get the job done. More importantly, they know how to put the ownership of the project back into the hands of the customer and not keep it to himself/herself so the client is always at his/her mercy.

We just got off the phone with a colleague who is trying to get a client back online with their small business server. The situation is dire because the server is not working properly due to multiple Trojan viruses, worms, and other viruses. And those are the simple problems.

The real problems are a result of the “high powered consultant” (and we are using those terms very loosely here) who originally configured the machine. The consultant used improperly licensed software (a.k.a., illegal) to create the server, illegally hosted websites on the server at the client’s expense and the consultant’s gain, registered the company’s domain address in such a way so only the consultant has the ability to configure the domain records, established several back door accounts with secret passwords in the event the client were to change the main password and a slew of other major and unethical offenses. Who knows what other data and information the consultant used to his advantage. Fortunately, the consultant has move onto other ground and has left the client in a lurch.

To top all this off, the client is really upset the machine is no longer functioning properly. The client is blaming my colleague for the malfunctioning even though the machine was not working properly before he came on-board (which is why the client called for a new consultant in the first place!) Yet the client stands firmly behind the expertise of the schlock consultant.

Facilitation requires we follow a five-step methodology: Problem/Opportunity Identification, Research, Design, Implementation, and Evaluation (presumably, the evaluation may identify something that requires another iteration of this process for continued improvement). A Real McCoy consultant will know how to manage this process and move you forward with tangible deliverables and results. A Wannabe won’t. And they may end up holding your family jewels as in the example above.

Professional Code of Ethics
As the Real McCoy, we hold ourselves to a higher standard than the Wannabe. We subscribe to acting in the best interest of our clients, providing service that is top quality and ethical. We do not meddle with unscrupulous behavior and walk away for improper, illegal, or unethical practices, even when there is money on the table to be had. Our reputation is more important that any amount of money and we protect our integrity above all else. Not everyone has their price – some are priceless.

As real consultants, we carry the insurances, accreditation, certifications and licenses necessary to ply our trade. No longer do we simply have a business license and workman’s comp, we go beyond that minimum. We continue to grow our knowledge through formal education providing our clients with the latest information.

Currently, American Eagle Group belongs to two groups that hold us to a higher level of ethical code. We have been members of the Independent Computer Consultants Association (www.icca.org) since 1993. Before we can become members, we must read and agree to the Code of Ethics. Violations to that code could result in expulsion from the organization. The expulsion would severely damage our reputation and impact our business.

As professional speakers, we are members of the National Speakers Association. Again, we must read and abide by the Code of Ethics. Violation of this Code can result in expulsion. Again, it would damage our reputation, impact our speaking engagements which would impact our consulting business. Violation of either Code of Ethics would severely damage our business.

We put our clients first. Pure and simple.

To some, this may sound idealistic, but not realistic. The fact of the matter, there are many consultants that hold to these values. Sadly, there are many more that do not. Your job, Mr./Ms. Client, is to determine who is the Real McCoy and who is the Wannabe.

We hope we have given you some food for thought. The next time you hire a consultant, poke beyond their flattery and boisterous claims. “Where’s the beef!” as the TV ad many years ago proclaimed. Not everyone is as they seem to be. See what certifications, ongoing studies and other pedigrees exist to support their claims.

You’ll find them if you want to.