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.


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.

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

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 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.

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

Seven Deadly Sins of Project Management

It has been reported in several articles that the next wave of C-level executives will be former or current project managers. Without much qualification, we can assume that they are the successful project managers. The premises for such a claim is that successful project managers know how to manage a budget, get things done, negotiate solutions, navigate the political waters, solve problems with a single bound, and resolve the daily conflicts that make up their every day world. Successful project managers also know how to not commit one of the Seven Deadly Sins of project management, thus avoiding the sabotage of their projects and helping them claim one of the few C-level offices.

How can we capitalize on the knowledge of these successful project managers and future executives? We need to identify the Seven Sins and excommunicate them from our lives. Over the past several months, I have been conducting a survey to help understand the current use of project management within organizations and the difference between successful and failed projects. From the study, I have seen consistently the following areas needing improving – the seven deadly sins:

  1. Lack of formally trained project managers
  2. No standardized project management practices
  3. Projects that linger forever
  4. Project suffering from scope creep
  5. Poor communications among team members, stakeholders, and others
  6. Unreasonable expectations on people, time, and money
  7. Incomplete definition of what was to be accomplished

Sin #1: Lack of Formal Training for Project Managers

Of all the people that I have trained in project management, I have not met one project manager that was trained in project management before he or she became a project manager. I find this curious. In fact, according to my study, only 24% of those managing projects, either part-time or full-time, have been formally trained in project management concepts. We seem to spend years in college and secondary education, pursuing various disciplines only to graduate, land jobs and then become project managers as if there were no need for formal training. We certainly wouldn’t go to an uneducated doctor or untrained mechanic, but we will use an untrained project manager for our $20 million project.

We see from industry studies that close to 60% of project fail and we wonder why. I would suspect the obvious in this case. What other area do we regularly take people, throw them into some position without training and expect immediate success? But we do that with regularity in the project management realm.

The obvious fix for such a situation is to educate the person on at least the fundamentals of what we are expecting so that they have a shot at success.

Sin #2: No Standardize Project Management Practices

It seems that with each new project, we must re-invent the wheel, taking a bit of what we have learned from prior projects and adding it to the new situation. Additionally, each one of us depends on our own talents and personalities and “roll our own” form of project management. The downside to this is that there is no consistency for either the management of projects or for our resources.

By standardizing the practices used for managing our projects, we gain by knowing a head of time what needs to be done, our team members know what to expect, the organization gains in efficiency and learning, and if we decide to ignore Sin #1, new project managers have something to follow as they enter the school of project management hard knocks.

Items to standardize: project plan templates, required documentation, status reporting, tracking of project progress, project initiation and definition, project planning, and so on.

Sin #3: Projects That Linger Forever

Some projects never seem to complete. They linger forever for several reasons: resources have been drawn onto other projects, company priorities shift, customer requirements are always in flux, sub-contractors and suppliers don’t provide needed materials or work, and so on. The list is endless. As a result, the project never finishes.

Projects that linger are damaging to the organization. No matter what stage they are in, they continue to cost money eating away at the time of those resources still involved, and kill morale within the organization. Additionally, it becomes a gnawing thorn to those who either worked or are currently working on the project. As people, we like closure to chapters in our lives, especially those chapters that are not the most pleasant. A lingering project is not pleasant.

There are two “simple” fixes to this sin: complete it or kill it. If you decide to complete it, you need to determine the reason for the project lingering. It is not always the obvious reason, so dig deep and determine the real reason. It may be that decisions weren’t made that caused the supplier to not provide the necessary material rather than simply their negligence. If you kill the project, make the decision and do it. Take the work that has been done, salvage the lessons learned and celebrate the “completion” of the project. Don’t make it a false celebration, but declare the project over appropriately so that the people put it behind them. Then move on.

Sin #4: Project Suffering From Scope Creep

We have all suffered from scope creep at one time or another. The scope of the project describes what the project is to do. Scope creep occurs when the definition expands during the course of the project. For example, I needed a light bulb on my car changed. I asked a mechanic to change the bulb. Thirty minutes later, he returns to tell me that my brakes needed to be fixed! They didn’t, but he tried to change a $15 job into a $350 job. That is scope creep.

We fix scope creep in one of two ways. Before the project starts, the scope is clearly documented and signed. The scope definition must include what the project includes and what it does not include. The “not included” is very important because it helps solidify the project boundaries. By referring to the scope document, we can keep the project within bounds.

When scope creep starts to occur, we use the document to bring the requester in line with the project parameters. If the requester insists on the change, we have the ability to request the necessary time and money incorporate the change.

Sin #5: Poor Communications

It is a well known fact, more people increases lines of communications exponentially. Keeping everyone informed becomes a daunting task. Even with the advances of communications such as email, cell phones, Blackberries, tele- and video-conferencing, web pages, etc., we still fall prey to uninformed people, information misinterpretation, or simply misunderstanding what was said.

This mis-communication becomes more complex now that we work across borders, cultures, and multi-generational workplaces. Words that used to mean one thing mean totally different meanings from one generation to the next. The expansion of our language with new words being added daily catches our breath away.

There is no simple cure to this sin. It takes diligence, ongoing learning of techniques, and the hardest behavior of all – listening to understand. These are behavior modification changes. Formal training in techniques goes a long way.

Sin #6: Unreasonable Expectations On People, Time, and Money

We have expectations. We expect people to do extraordinary things in limited time with little money. I find it interesting that, because of that expectation, extraordinary accomplishments result. So we live with this double-edged sword. If we truly had all the money, time, and people needed to accomplish a project, would we? And yet, we continually feel exasperated and drained because we are always under the gun to produce.

In a speech given by Pres. John F. Kennedy in 1962, he made the statement that by going to the moon in the next decade, it would prove that we had taken on a hard task that would prove the skill and fortitude of the American people. It builds pride in me every time I hear it. It makes me rise to the challenges.

We must know how far to push the envelope of expectations to gain the best but not so far that we over extend the money, time, and people into failure. And when the team accomplishes the task, we need to make sure that we acknowledge their effort in a great way, not just a simple thank you.

Sin #7: Incomplete Definition

The funny thing about this sin is that many times, we don’t realize that we have an incomplete definition until we are well into the project. The definition’s incompleteness becomes painfully obvious. Even worse, when we spend the “proper” amount of time defining the project and are crystal clear on the definition, we can still end up with an incomplete definition.

With that being the case, we need to be vigilant in our definition efforts to have as complete as possible definition prior to the project and to be nimble to incorporate definition refinements during the project. It takes skill and aplomb to make that happen. Stakeholders will need to be apprised of the impacts and made a part of the definition process, prior to and during the project. Once the area of definition deficiency is identified, we need to work quickly to determine its clarity and incorporate it into the project flow to keep things on track.

Final Thoughts

In life, there are many sins that we may commit. In project management, there are more sins than these seven that we can commit. Those are topics for another time. From my studies and questioning of people, these are the top seven. While at times they can be fatal or at least appear to be fatal, with some forethought, planning, and awareness, we can side-step many of them. So, go forth project managers and sin no more.



David A. Zimmer earned his Ph.D. in Project Management from the University of Hard Knocks. After twenty-five years of experience, he attended Villanova University for formal training and much eye-opening. While he is a highly effective and successful project manager, project management would have been much easier had he been trained first. He is now an evangelist coaching and training others in proper project management methodologies.

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