Why Formalize Project Management – RTMI Baby!

RTMI - Repeatable, Trackable, Measureable, Improvable

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

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

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

Processes make what we do:

  • Repeatable
  • Trackable
  • Measurable
  • Improvable

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

Processes are Repeatable

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

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

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

Processes are Trackable

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

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

Processes are Measurable

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

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

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

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

Processes are Improvable

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

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

Consequences of Process

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

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

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

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

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

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

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

Conclusion

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

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

 

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

IT Cube – Six Perspectives to Project Requirements

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

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

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

What’s the PMBOK® Guide Say?

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

What’s the BABOK® Guide Say?

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

What is IT CubeTM?

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

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

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

The Six Perspectives

Six perspectives for any project exist. They are:

1. The “Technician”

2. “Technical” Management

3. Business Management and Executives

4. The User or Customer

5. Analysts and Pundits

6. Vendors

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

Let’s define each and understand their needs.

Panel One: The “Technician”

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

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

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

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

Panel 2: “Technical” Management

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

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

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

Panel 3: Business Management and Executives

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

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

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

Panel 4: The User or Customer

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

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

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

Panel 5: Analysts and Pundits

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

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

Panel 6: Vendors

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

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

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

Conclusion

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

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

Tell Us What You Think

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

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

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

Project Management and ITIL for UC: Recipe for Sanity

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 © 2008, David A. Zimmer, PMP All Rights Reserved

When Solving A Problem, Get To The Root Cause, Don’t Redefine The Symptom

I recently read an article appearing in CIO Magazine titled “Common Project Management Metrics Doom IT Departments to Failure” where the subtitled mentioned a report by Forrester Research stated the metrics used to measure IT project success influences the perceptions of failure. It goes on to say that we need to change to increase the perception of success instead.

We’ve all heard the adage “perception is fact” implying perception is not fact, it only has the allusion to be factual. I don’t know if it is my sense of humor, but the statement of “increase the perception of success” was strangely funny. Did it mean the project was actually a failure but we make it appear successful? Does it harken to another well-tread cliché, “In project management, we simply redefine the parameters and declare victory. That’s how we have successful projects!”

The article further details four things the PMO can do to help increase the perception of success. While I agree with them:

  • keep project steering committee on task,
  • improve communication with project sponsor about changes,
  • improve reliability of project plans, and
  • better communicate estimates of costs, schedule and resources;

I believe they miss the fundamental basics of the problems – the root causes.
According to the Standish Group, IT projects have only a 29% chance of succeeding. You would think with the advance in technology, the development of quality processes and increase of understanding humans; we’d have a better shot of being successful. In 2003, the Standish Group estimated we spent $382 billion on IT projects in the US alone. They further stated $82 billion was an outright waste. Using the 71% failure rate, we spent $271 billion on failed projects. Maybe that’s why we need to increase the perception of success – so we can balance the books!

Based upon my years of managing IT projects (I’ll admit, not all were successes, perceived or otherwise) and experience training more than a thousand people in the art of project management, I believe the following are the root causes for IT project failures.

1. Project managers are chosen, not trained.

In my training seminars, I ask how many people actually chose project management as a career. I have had only three people raise their hands. Usually, we are selected because we are doing well in our “real” jobs and seemed to be organized getting things done. One day, as we arrive in our office, twang, we are dubbed project managers. No training.

Then I ask how many have any sort of formal training in managing projects. Regardless of the industry, the percentage is basically the same, only 20% have had any form of training. I reduce the definition of training to the ridiculous of a one hour discussion and very few additional hands go up. Only 5% have more than a day and 1% go on to be certified through Project Management Institutes’ Project Management Professional certification.

It is not we aren’t intelligent and can’t learn the ropes, but usually we learn by observing others who have gone before us. They learned the same way – by observing others. As a result, improper methods are learned and used rather than industry accepted practices. We just gitter dun – whatever it takes, nights, weekends, extra shifts, Herculean efforts – we gitter dun.

As a result, we don’t put the proper measures in place to give the information business people need. Worse, we really don’t know where we stand in our own projects. We can’t repeat our successes because we don’t know what we did to be successful. We don’t always learn from our mistakes so we are doomed to repeating them. And finally, many projects we considered successful really weren’t causing us to repeat bad habits because we believe they are good practices.

Through training, we learn proper techniques, why certain processes should be followed and the tools we need as project managers. To contrast untrained project managers with a failure rate of 71%, studies have shown using trained and certified project managers – PMPs specifically – succeed close to 75% of the time.

Root cause #1: project managers aren’t trained to do the job we ask.

2. No formal change process in place to determine success or failure.

In the CIO magazine article, someone placed a comment contrasting construction project management with IT project management. He stated IT methods are primitive to constructions processes. I agree totally.

First, construction follows a methodical, time-proven method. They work from blueprints with every detail shown. They research the site and understand what lies hidden before digging. They understand the necessary inventory of materials and labors in advance of the start date. But most importantly, they have a change process.

Once the deal is signed, any changes to the agreement require a change order with signatures. The change order details the impacts to schedule, increase to budget, amendment to the project scope, etc. Each party must sign before the change occurs, otherwise, the original plan holds. No changes are made unless the boss says so.

In IT, we take a different tack. Again, from my survey of many attendees, only three or four people stated their company had a formal change form and process. Worse, they reported changes to the project can come from any where through any channel to any member of the project team. Since many things are considered “easy,” the impact to the rest of the project and beyond is never considered. If a change is formally documented, no one dares sign it. Accountability is forbidden.

As a result, what is defined to be the project is not really the project. As time passes, changes are requested but not tracked. The project morphs and twists into something other than the original definition. As a result, the original project may have been successful using the traditional metrics, but no one can prove it because no clear definition of the project exists.

Additionally, changes come through various portals. There might be a formal request sent from the CIO to the IT project manager. Another request comes from the sales manager tapping someone on the shoulder in the hallway. A third and most insidious is the IT staffer who “sees something needs to be done, and does it” without tracking the impact to the overall project.

Solution for such a situation is two-fold: a well defined and followed project scope and a formal method for requesting changes.

Root cause #2: No formal change process which defines a single point to funnel change requests.

3. Project Expectations Not Defined In Detail

A successful project must meet the expectations of the stakeholders. Even if it comes in on budget and on time, if it doesn’t meet their expectations, it failed. Unfortunately, we don’t document the expectations. We document the technical requirements, the inventory list of hardware and software needed, select the team of implementers, etc., but we don’t seem to jot down the expectations.

If we don’t document the expectations, how do we know when we are finished? If the expectations are met, we would have success by definition, correct?

Of course, the stakeholders don’t always reveal their expectations for us to conveniently document. In fact, their expectations change over the course of the project. Even if we met the original expectations, we still fail because we didn’t meet the current list of desires.
As a result, project managers must spend a good deal of time understanding the stakeholders’ motivations, desires, intents, and rationale for the project. Periodically, he must check in with the stakeholders to verify current understanding of their needs and make adjustments accordingly.

Root cause #3: lack of understanding expectations leading to no formal documentation listing motivations, desires, intents, etc. of stakeholders.

Conclusion

I don’t feel it is right to simply change the perception of IT project success. To me, that’s cheating and we don’t solve the real issues. We need to change how we “do” IT project management to be successful. Proper training is key number one. I, like many, managed many projects before I was formally trained. Boy did I learn about my bad habits and improper ways of managing projects. As I instruct others these days from my lessons learned, I see the same transformation in them.

IT doesn’t have to suffer the fate of poorly run, failing projects. Solving the root causes for those problems would go a long way in better return on investments, fewer dollars wasted, and happier IT people. Once these are fixed, we can begin to work on the list from the CIO article.

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

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

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

Why Utility Services?

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

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

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

Conclusion

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

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

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

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

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

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

Fig. 1: Three Avenues To Better IT Infrastructure Services

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

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

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

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

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

Fig. 2: PMO, CobiT, ITIL Integration

Business Requirements and Drivers

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

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

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

IT/IS Systems, Infrastructures – Realities

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

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

PMO – Project Management Office

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

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

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

ITIL – Information Technologies Infrastructure Library

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

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

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

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

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

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

CobiT – Control OBjectives for Information and related Technologies

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

Conclusion

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

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

 

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

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