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

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

Why Utility Services?

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

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

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

Conclusion

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

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

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

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



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

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

Fig. 1: Three Avenues To Better IT Infrastructure Services

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

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

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

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

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

Fig. 2: PMO, CobiT, ITIL Integration

Business Requirements and Drivers

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

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

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

IT/IS Systems, Infrastructures – Realities

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

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

PMO – Project Management Office

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

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

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

ITIL – Information Technologies Infrastructure Library

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

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

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

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

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

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

CobiT – Control OBjectives for Information and related Technologies

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

Conclusion

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

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

 

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



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.

Credentials

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.

Objectivity

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.

Conclusion

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



Project Management – Like Crossing the Street

Recently while giving a presentation to a potential client, I used an analogy of crossing the street. I said:

“Project management is a lot like crossing the street. You can listen to others who have gone that way before and heed their advice. Look both ways, make sure the way is clear and cross before oncoming traffic hits you. Or, you can simply jump out into the street and see what hits you and then deal with the issues that arise.”

Sadly, too many people and companies people take the latter approach. From our study conducted in January and February 2006, we learned that 76% of project managers are not formally trained in project management. They are intelligent people, probably very good at what they were trained to do. But somehow, they were volunteered to manage a project and were not given the training to do the job properly. As a result, they struggled to make the project a success.

Experience shows that even though you are confident in what you are doing, it is always good to have someone watching your back and helping in areas that are new, even though they look very similar to the past. I learned this lesson, almost to my demise, while crossing a street in England. I was ready to cross a road, had my foot off the edge, when I was quickly yanked back to the curb. I was indignant at the person who would do such a thing. I had looked and the way seemed to be clear. I had successfully crossed many streets in my life. But just as I was going to say something to the person who yanked me, a car went whizzing by me and nearly clipped me. I had looked the wrong way! It would have been a fatal mistake. Another perspective on the situation saved my life. My indignation turned into gratefulness.

American Eagle Group provides that extra perspective. We have crossed many streets successfully – not always without incident though. We have the scars to prove it! Through our “coaching” services, we help you make more informed decisions. We help you see the way more clearly.

One of our clients used our service and saved over $5 million dollars! They were embarking on a new marketing campaign. They wanted us to provide a sanity check on the project plan and roll-out. While the intent was to make sure the “project management” was sane, our understanding of the market and the broader scope helped us to show them the fallacy of their thinking. Yes, we could have helped them manage their project successfully, but our greater understanding of project management show us that the stakeholders’ expectations would not have been met properly – a successful launch of the product and the wise use of $5 million. The project would have been a failure and a waste of the valuable $5 million.

Another client asked us to determine how they would make money from a particular project. The project had already been underway for two years with more to follow. The annual budget for the project to date was $90 million ($180 M total) with increased budgets to come. So it was critical to understand the profit potential for such a project. After careful analysis of the business plan, we determined that expenses on the project were 77% of the potential revenue. That 77% of the revenue represented operation expenses and did not include the overhead of the ongoing development of the project or other corporate overhead! As a result, the project would never had made any money. We recommended that the project be cancelled based upon the financial analysis.

We felt like that person who saved my life in England by yanking me back from a speeding car coming for a direction I was not looking. These are just two examples of times when people, confident in what they were doing, looking the wrong way when something was coming from the other direction. We were there to help save them from certain disaster.

So, the next time you wade out into the street, make sure someone is watching your back!

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.

 

Bio

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