What is a frog?

Right now you are probably thinking of a small amphibian with long legs that some like to eat. But, the word frog has many meanings:

• A decorative clasp joining the collar of a cape.
• A metal plate used in railroad switches and crossings to guide the wheels across gaps.
• A device used for arranging flowers.

Actually, there are more than twenty different meanings for the word frog. The one that correctly conveys the user's meaning depends on the context within which it is used.

The traditional professions, law and medicine promote clarity in communication by using Latin. They chose Latin because it is a dead language; that is, it is no longer spoken by a living population and, thus, the meanings of words will not alter through popular usage. Unless the human body mutates radically, an ulna will be an ulna forever and legal scholars who depend on the stability of precedent will interpret a mensa et thoro with unwavering regularity.

The Language of Project Management

Since the founding of scientific management during the Industrial Revolution and during its metamorphosis into the modern practice of project management, different words have been used to convey the same meanings. For example, tasks in Microsoft Project (arguably one of the most popularly used computer applications to plan and monitor projects) are referred to as scheduled activities in more traditional applications. Apparently fearing that the lack of a professional etymology for all terms used in project management might be at the root of failures and cost overruns, the Project Management Institute (PMI) has set itself a goal:

“The PMBOK® Guide also provides and promotes a common vocabulary within the project management profession for discussing, writing, and applying project management concepts. Such a standard vocabulary is an essential element of a professional discipline.”

Inasmuch as PMI has not shown any inclination to adopt a dead language for their professional vocabulary they must devise and implement it using the popular vernacular of each country in which they operate. I do not know how much success they are having in other countries but in America their success thus far has been somewhat spotty. Consider the following example:

PMBOK® Version 3 defines task as “A term for work whose meaning and placement within a structured plan for project work varies by the application area, industry, and brand of project management software.” Ignoring for a moment that they aver that task is synonymous with work, they are correct in their assertion that the usage of task varies. However, it is difficult to find any application area, industry or brand of project management software that uses task synonymously with work as PMI defines work; “Sustained physical or mental effort, exertion, or exercise of skill to overcome obstacles and achieve an objective.” Sorry, that is not how others use task. In popular usage, you may assign a task or work to someone and mean approximately the same thing. But, using them as verbs, “tasking a person” and “working a person” have completely different meanings. Generally, in project management task refers to a scheduled activity and work refers to the effort required to complete a task.

Fortunately for students of PMBOK® there are only two occurrences of task within the entire text and both may be interpreted accurately relying only on popular usage. They will be led astray only if they attempt to interpret if they have been using Microsoft Project and attempt to interpret it as a scheduled activity when they read the following from the 3rd Edition:

“For example, late recognition that the legal department was a significant stakeholder in a year 2000 rollover (Y2K) software upgrade project caused many additional documentation tasks to be added to the project's requirements.”

“Additional documentation tasks” is easily interpreted so long as the reader does not apply the definition of task as provided in the Glossary of the 3rd Edition of PMBOK® in which this quote appears. Tasks interpreted as scheduled activities are incremental steps in the logical network of a project plan. Again relying on the Glossary, tasks are not a part of a project's requirements.

Jumping to the defense of PMI, we must observe that PMBOK® Version 3 has been replaced. Let's see how PMI handles the issue in the recently published 4th Edition of PMBOK®. Looking to its glossary we find that both task and work are now omitted! Surely then one might think that they must have removed all references to task from this new edition. However, we find there are twelve references to it in Version 4 whereas there were only two in Version 3! How then are project managers to define its usage in each case as they read and study PMBOK®?

Ambiguity Has No Place in a Professional Vocabulary

“Do as I say, not as I do” does not work for leading or inspiring others to adopt a professional vocabulary any better than it works for parents attempting to civilize their children. For PMI to effectively promote adoption of its professional vocabulary it must use it themselves and use it consistently; especially in PMBOK®.

A lack of consistency in both PMBOK® Version 3 and Version 4 is clearly evident using just one example; the usage of stakeholder.

Stakeholder has long been used popularly to identify those with the greatest interest in the outcome of a project; those who pay for or approve its deliverables. PMI attempted to clarify this by including the following definition in the Glossary of their 3rd Edition of PMBOK®:

“Stakeholder. Person or organization (e.g., customer, sponsor, performing organization, or the public) that is actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables.”

This definition was greatly expanded and expounded upon in section .2 of Chapter 2 of the 3rd Edition of PMBOK®. It averred that key stakeholders include the project manager, customers/users, the performing organization, project team members, the project management team, the sponsor, influencers, and the project management office (PMO). In other words, any one or any group that has an interest in or influence over the outcome of a project.

Curiously, stakeholder was omitted from the Glossary of the new 4th Edition, however, Chapter 2 provides the same definition as found in the Glossary of the 3rd Edition and reaffirms the above list of stakeholders then adds a few more.

Generally, however, most references to stakeholder throughout both editions of PMBOK® are ambiguous. They do not differentiate which key stakeholder is implied. While some references are easily interpreted, many are not. For example:

“When dealing with any stakeholder, practitioners should be committed to honest and fair practices and respectful dealings.”

“Enterprise environmental factors include, but are not limited to... Stakeholder risk tolerances.”

“The generic life cycle structure generally displays the following characteristics... Stakeholder influences, risk, and uncertainty, (as illustrated in Figure 2-2) are greatest at the start of the project.”

“Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the project life cycle. Their responsibility and authority may range from occasional contributions in surveys and focus groups to full project support, which includes providing financial and political support.”

“The PMO can provide... Centralized communication among project managers, project sponsors, managers, and other stakeholders.”

The connotations to be applied to the use of stakeholder are easily interpreted in the first and last above cited examples. In all others, there is ambiguity. Such examples abound in both editions of PMBOK®.

Last Word

Some may argue that all of the above examples of the usage of stakeholder can be interpreted with a little common sense. However, common sense is an uncommon commodity. That is why we are admonished to “Say what you mean and mean what you say” in contracts, raising children, and building relationships as well as in setting standards for professional practices.

Generally, the 4th Edition of PMBOK® vastly improves on the 3rd. PMI has repaired some portions and yet others remain in need of attention.

Throughout this paper it has not been my intent to be critical of PMI and its publication but rather to provide constructive criticism. As a student of Law holding a Juris Doctor as well as having more than 30 years experience managing and often rescuing projects I believe that PMI is on the right track but have not yet arrived at their journey's end.

About the Author

Jack Durish is the Interim IT Executive. He has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.

Jack has more than 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.

Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as IT courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.

Visit his website at http://www.ironlantern.com/

A Risk for All Projects

“Any job worth doing is worth doing twice.” – Anonymous

Have you ever completed a project that developed a unique product, service, or result that no none wanted? It's happened, you know. Even though the project team completed all the work proscribed in the project scope. Even though they finished on time and on budget. Even though they satisfied all quality standards. Still, no one wanted it. It couldn't happen to you? It could. It happens whenever there is a disconnect between business needs and what stakeholders may communicate they need. This disconnect occurs far more frequently than one might imagine. Successful project managers learn to recognize this risk and avoid or mitigate it. Unsuccessful project managers fail and take the blame. (Seriously, do you think anyone else is going to accept blame?)

A project that delivers an unacceptable result is arguably far worse than one that is cancelled or runs over-budget or over-schedule. By definition, the project is complete and the entire budget is spent. There is nothing left to fund a do-over; especially, not in a challenging economy.

How do project managers prevent such a result?

For those familiar with PMBOK®...

Progressive elaboration, as the Project Management Book of Knowledge (PMBOK®) defines it, is a technique for “continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and thereby produces more accurate and complete plans that result from successive iterations of the planning process.” Like most topics in PMBOK®, this is good information as far as it goes and depending upon how it is interpreted.

One cannot argue with the admonition to continuously improve and detail the project plan during successive iterations of the planning process. But, how about the principal product of the initiating process; the project charter? Should it be revisited periodically to insure that the major deliverables of the project will satisfy the real business needs of the sponsoring organization? Should it be revisited to insure that the project plan is on track to deliver a result that meets those needs?

The PMBOK® definition of the project charter does not include its content. It simply states that it is “a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.” However, in describing the process to develop the project charter it says, “It is the process necessary for documenting the business needs and the new product, service, or other result that is intended to satisfy those requirements.” We must then infer that these elements too should be found in the project charter.

Inasmuch as PMBOK® specifies that the project charter is an input to the planning process, it explicitly justifies revisiting the charter during progressive elaborations. Revisiting the project charter does not necessarily imply that it should be changed. Indeed, changes in the project charter will ripple throughout every aspect of the project plan as well as all subsidiary plans including the Risk Management Plan, the Staffing Management Plan, etc. Thus, charter changes should not be introduced lightly. However, care should be taken throughout the life of the project to insure that all stakeholders share a common vision of the business needs being addressed in the project, its plan, and its intended major deliverables and that the project is always on course to satisfy those needs.

For those not so familiar with PMBOK®...

Project managers must constantly challenge and check their understanding of the sponsor's intent in authorizing the project throughout its entire duration. What is the business need being addressed by the project and what are the criteria by which the major deliverables will be judged? Progressive elaboration is a process by which project stakeholders continuously monitor their shared understanding of the project and revise its plan as necessary to insure that the product, service, or result of the project will be accepted.

There is one person who can prevent progressive elaboration from accomplishing this goal; the gatekeeper.

Gatekeepers

Gatekeepers are people who control access to individuals and groups in an organization. Salespeople have been plagued by gatekeepers since the first Neanderthal tried to sell fire to a neighboring clan and was stoned by sentinels outside their cave. And, as every salesperson will tell you, it was their loss; that other clan really needed fire. Well, there are gatekeepers who keep project teams from gaining access to those with key information and insight necessary to the success of the project. They often keep the project team from collaborating directly with key stakeholders. Sometimes they function as a clearing house for input from other key stakeholders. In other words, they are holding themselves out as having all responsibility and authority for elaborating the project and its plan themselves.

Transferring responsibility for progressive elaboration from project managers and their teams to a gatekeeper is a prescription for disaster. Remember the exercise in school where the teacher lined up the class and whispered a secret message to the first person. As the message was whispered from one person to the next it was distorted until the last person heard entirely different than the message the teacher initiated. The same happens when gatekeepers filter the knowledge, needs, and advice of key stakeholders to project managers and their teams.

Keep in mind that all gatekeepers have some degree of influence or authority over the project; more so than the average stakeholder. They are generally superior to the project manager. Thus, they must be handled carefully.

Avoiding Gatekeepers

There are two principal methods of avoiding or mitigating the effects of gatekeepers; one using subtlety and the other brute force. Always attempt the former first and the latter when the first fails. In no case should gatekeepers be allowed to succeed in preventing direct contact between project managers and their teams and key project stakeholders.

The avoidance or mitigation strategy best employed most likely will be determined by the motivation of the gatekeeper. Some gatekeepers feel they need to filter all communications during the elaboration process because they do not trust other key stakeholders. Either they may feel that only they correctly perceive project goals and needs or that other input will lead the project team astray. Others may insert themselves into the role of gatekeeper because they do not respect the ability of the project manager to adequately mine the stakeholders for the required input. There may be cases where project sponsors mistakenly authorize the arrangement. Regardless, project managers must begin by developing a close relationship with the gatekeeper to ascertain their motivation and select the best strategy for avoiding or mitigating the risk they represent.

Googling “getting past the gatekeeper” will provide tens of thousands of links to web pages offering good advice for salespeople. Interestingly, many of their strategies and tactics can be applied to project teams who encounter gatekeepers. Ultimately, the best advice is found at the top of most lists: “Turn Gatekeepers into allies: treat them with respect, humor, and compassion. Their jobs can be tough, too. They get it from both ends. Regard them as people with their own personalities, not as faceless obstacles to overcome at all costs.”

Gatekeepers who lack trust in their associates may be best handled by inundating them with tasks to the point that they will be forced to delegate them to others. This will either prove to the gatekeeper that their associates can be trusted or to the project manager that they, in fact, cannot. Testing and evaluating early project activity and phase deliverables provides an excellent opportunity to employ this tactic.

Gatekeepers who lack trust in project managers and their teams may come around, if they are reasonable, after the team has had an opportunity to demonstrate its competence in the early activities and phases of a project. If the gatekeeper continues to insert themselves into the process to the detriment of progressive elaboration, it may help to arrange demonstrations of the effects of their behavior during general project meetings. Hopefully, the gatekeeper's interference will be perceived and someone in authority will take corrective action. Failing this, the project manager may have to escalate the issue to someone superior to the gatekeeper for resolution. Remember, once this tactic is chosen there will be repercussions. Do not embark on this path lightly.

The most difficult situation to reconcile occurs when a project sponsor designates a gatekeeper. They won't be known by that title but they will perform the function. In effect, the sponsor is ignorant of the project manager's role in this regard or, worse yet, they lack confidence in the project manager's ability to perform it. Dealing with this situation takes great patience and finesse. Project managers may be able to educate the project sponsor or demonstrate the problems being created by their poor command decision. Granted, the odds are stacked against success. However, failure to correct the situation is bound to end in an even greater disaster.

Conclusion

Gatekeepers may be encountered in any type of project and represent the same risk in all making this a subject worthy of further discussion and study. It would be helpful if others shared their experiences with gatekeepers in projects and their success or lack thereof in avoiding them or mitigating their impact.

About the Author

Jack Durish is the Interim IT Executive. He has more than 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.

Jack has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.

Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.

Visit his website at http://www.ironlantern.com/

Just Say No to Email

“What we have here is a failure to communicate.” – The Captain in Cool Hand Luke

Actually, no. What we have is way too much communication and not enough collaboration. Just look at your email inbox. SPAM filters are somewhat effective at blocking unsolicited commercial emails and bulk mailings but not the junk mail from your friends and coworkers. This flood of communication attacks our ability to focus attention on what is important.

Additionally, email suffers from four significant failings, any one of which could render it an unsuitable choice for business collaboration:

Email Is Not Secure

Intercepting email is expensive. However, if your organization or the one you are working with is a leading competitor in its industry then someone may be willing to pay the price. Actually, this is the one time that SPAM may be your friend. Anyone interested in your email not only has to have sophisticated technology to intercept your email and high-price operators to use it but also has to sort through the SPAM to find anything of value. In practice strategic military facilities send each other SPAM all the time to help hide their classified transmissions.

Email can be encrypted but rarely is. Most users do not know that it can be encrypted and, even if they do, few of them know how to do it. It is possible to encrypt emails transiting between organizations that have dissimilar email systems; however, users have to request this service and administrators of the sending and receiving organizations have to configure their servers to use a common encryption paradigm. Larger organizations using more sophisticated messaging systems have extremely strong, dual-key encryption for their email but, again, users rarely employ it. Most are blithely unaware that their messages are at risk.

You might suppose that internal messages are safer than external ones. However, the vast majority of security breaches are internal. Few users are aware that email administrators can read their messages. Thus, I could easily pay one of them to intercept your email for me bypassing the need for sophisticated interception technologies. The only protection you have against someone accessing your mail file directly is encryption. Alternatively, you can create the content of your messages as encrypted text files and email them as attachments.

Email Is Not Manageable

Managers are not aware of email exchanges between subordinates unless they are copied and, if they are copied, they often are inundated with so much email that they hardly have time to review any of it adequately. Thus, employees may be wasting time on activities that are not authorized or desirable.

Worse yet, employees may be exchanging messages with outside vendors that materially alter or affect contractual relationships. Managers may not become aware of these until it is too late to correct them. Granted, employees can be trained and warned against inappropriate communications and contracts can be written to avoid any unauthorized changes but sorting out disputes, even successful ones is a costly business that only the lawyers win.

It is impossible to moderate a an email discussion thread unless the moderator is copied on all emails that comprise it. Also, when new members join the team or business unit mid-way into an important discussion, they do not have access to earlier messages unless someone forwards these to them.

Email Is Costly

Basic email service is cheap enough. Even factoring in the licensing costs of servers and individual workstation clients, monthly email service may be as little as $25 per user. However, when you begin adding special services to block SPAM and insure security, the cost quickly rises. Furthermore, multiple addressees on emails require greater enterprise bandwidth to transmit the messages and, if they contain even modestly sized attachments, greatly increased storage capacity to store everybody's copy.

Again, more robust systems have provisions to store only one copy of the attachment that all addressees may access. Still, I have rarely found email administrators who have had the foresight to enable this feature.

Email Is Not collaborative

Email is a means of communication. Are collaboration and communication not the same? Emphatically not. Communication is a flow of information; collaboration is joint activity with sharing of resources. Communication is a one-way transmission of information; collaboration could theoretically be completely silent while two or more people work together toward a common end.

Asynchronous Collaboration

Groupware is an example of asynchronous collaboration wherein members of a team take turns contributing to the group effort. They are among the first applications to take advantage computer networks in general and the Internet in particular. Interestingly, the current Wikipedia article on collaborative software includes email, calendaring, text chat, and wiki in this category which serves to illustrate that this is not a truly reliable source of information. Text chats and wikis did not exist when groupware came into being. In fact the best examples of early groupware applications included email as an accessory but this served only to alert users that content was available to be shared or their attention was need to take action on it. Shared calendars, on the other hand, are the only one of the four features mentioned in the Wikipedia article that was included in early groupware and helped people collaborate. It allowed them to schedule their time as a group and, thus, coordinate their collaborative efforts.

Some groupware applications have extremely robust security apparatus. Dual-key identities for user authentication and authorization as well as file and data exchange encryption is extremely difficult to circumvent and make groupware the obvious choice for collaborating with highly sensitive documents and data.

More than 20 years after their introduction groupware applications remain a powerful tool for collaboration. They include provisions for workflow applications wherein documents progress through a well-defined and well-managed process. The documents are stored in a central file to which users connect in sequence to perform their assigned operations.

A less sophisticated form of asynchronous collaboration began when users simply stored files in a common network location and others accessed them as necessary. Simple directory permissions were used to control who had access to these files. Document sharing programs evolved to provide a formal structure to this process. Like groupware, the documents are stored in a centrally located database file. Typically, they provide document check out and check in locks to insure that two people do not attempt the edit the same document simultaneously. Some have accessory applications like group calendars and may be confused with groupware. However, they do not have the more advanced groupware features such as workflow and their document security apparatus is likely to be less robust.

Synchronous Collaboration

Instant messaging (IM) or text chatting is the most obvious example of synchronous collaboration wherein two or more users are working together in real time. Some might argue that IM is, like email, little more than a means of communication. However, email is not synchronous and it is that quality that moves IM into the realm of collaboration. If you choose to use email for business collaboration, do not use a publicly available medium. These are easily intercepted. Choose one that can be encrypted and allows for recording of chat sessions so that collaborative exchanges can be preserved.

On line meetings are also synchronous and a major tool for collaboration. Again, do not use ones that are publicly available to share sensitive materials. Choose one that can be encrypted and allows for synchronous editing of shared documents.

Conclusion

Breaking the email habit is not easy but there is no excuse not to try. The shortcomings of email are severe and there are alternatives that have far greater capability.
Do not confuse communication with collaboration. The next time you click “New Memo” stop and think: “Do I want to work with them or pontificate at them?” Your choice will be clearer then.

About the Author

Jack Durish is the Interim IT Executive. He has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.

Jack has more than 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.

Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as IT courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.
Visit his website at http://www.ironlantern.com

The Secret Identity of IT Project Sponsors

The character of Pope Julius in the 1965 film, The Agony and The Ecstasy pleads with Michaelangelo who is painting the ceiling of the Sistine Chapel, “When will it be done?” and Michaelangelo responds testily, “When it is finished!” Most project sponsors should be able to identify with the Pope's frustration. His project manager (Michaelangelo) is dedicated to his project but oblivious to the Pope's greater concern: the Sistine Chapel. Those who do not emphasize with their sponsor's concerns are destined to discover the agony of project management that can tarnish their ecstasy, even those completed on-time and on-budget.

The Project Management Body of Knowledge (PMBOK®) is far too limited when it comes to identifying project sponsors and defining their concerns. It states that sponsors are project stakeholders together with project managers, customers/users, the performing organization, project team members, the project management team, influencers, and the PMO. It states that sponsors are synonymous with “project initiators” who provide “the financial resources, in cash or in kind, for the project.” PMBOK® further states that:

• Sponsors are “external to the project organization...”“For internal projects, the project initiator or sponsor provides the statement of work...”
• “The preliminary project scope statement is developed from information provided by the project initiator or sponsor.”
• “Every documented requested change must either be accepted or rejected by some authority...” which may be the sponsor.
• “The project sponsor... [among others]... often dictates key events or major milestones or major milestones...”
• “QA support... may be provided to the project team... by... [among others]... the project sponsor.”
• “The project sponsor works with the project management team, typically assisting with matters such as project funding, clarifying scope questions, and influencing others in order to benefit the project.”
• Inferred throughout PMBOK®, project sponsors are the ultimate authority to accept or reject the project charter and all project deliverables.

Obviously, PMBOK® is not meant to be a guide for project sponsors. They would be lost with such scant information. However, it is a guide for project managers who need a far better understanding of sponsors' identities and roles so that they can better respond to and satisfy them. It may have been adequate in the time of Michaelangelo who only had one sponsor. Today's IT project manager has at least five: the person or group who controls IT principles, IT architecture, IT infrastructure, business application needs, and IT investment and prioritization. Even if all five are embodied in one person, the project manager must address the needs and concerns of all five roles throughout the project life-cycle.

IT Principles

How is IT used in the business? IT projects have a far better chance of succeeding if they are consistent with that vision. If that vision is not clearly stated, the project is at risk regardless of whether or not it is consistent with any implied or inferred vision.

If the sponsoring organization does not have an explicit set of IT principles, you can discover them by finding answers to the following three questions as propounded in IT Governance by Peter Weill and Jeanne W. Ross:

• “What is the enterprise's desired operating model?
• “How will IT support the desired operating model?
• “How will IT be funded?

“The first two questions specify how an enterprise develops and delivers products and services and clarify the parameters for future infrastructure and application decisions. Answers to these questions evolve to reflect organizational learning and new business strategies. The third question determines the broad criteria for IT investment. Specifically, IT investments may be funded centrally or within business units, or some combination of the two approaches can be applied. The funding model specifies whether enterprise-wide priorities or business unit priorities take precedence in investment decisions.”

What if you found yourself managing a project that was not supportive of the enterprise's desired operating model? For example, imagine that your project is sponsored by the accounting department to deploy a billing system that is not compatible with an ERP system that the organization is planning to purchase; one that would integrate order processing and billing. What would you do?

IT Architecture

Generally, every organization's IT principles will include a provision for cost control and operational efficiency. An enterprise architecture that promotes process and data standardization is crucial to achieving these goals. Thus, IT architecture is the organizing logic for data, applications, and infrastructure, captured in a set of policies, relationships, and technical choices to achieve the organization's IT principles.

Currently, top-performing organizations publish policies that specify their technological choices and enforce standards in enterprise components and services. Typically, they will avoid deploying new systems that are not consistent with these. Still, there are far too many who have not expressed their policies in such a clear and consistent manner.

What if you found yourself managing a project that employed data that was not standard within the enterprise? For example, imagine that you are managing the deployment of a new application that required a specific user directory that is not currently supported within the enterprise. Most organizations have spent years consolidating multiple directories into one enterprise standard and are unlikely to welcome another. Project sponsors who lack explicit policies to guide them or do not have the technical acumen to recognize this conflict may overlook it when they charter the project. What would you do?

IT Infrastructure

An enterprise infrastructure based on an agile and disciplined architecture provides a solid foundation for today's applications as well as tomorrow's. Typically, it includes:

• Human and technological resources
• Shared information technology services
• Shared and standard IT applications

Currently, most high performing organizations are exploring or deploying services-based infrastructures. Managers appreciate the value of a service far more than a technological component. Furthermore, services-based infrastructures are more adaptable to change at a much lower cost and with little or no disruption to other services or systems. But, most still employ a component-based infrastructure and you may find yourself managing a project there.

What if you found yourself managing a project to configure and deploy an emerging technology in a component-based infrastructure? By definition, such a deployment may significantly change the infrastructure on which all enterprise applications are based. There is no problem inherent in such a situation unless the new deployment will interfere with existing applications. You cannot assume that technologically astute sponsors are aware of this problem. They may be relying on vendor representations that are not accurate. Salespeople may inadvertently make false representations and their supporting technicians may not be inclined to correct them for fear of being blamed for the loss of a sale. What would you do?

Business Application Needs

While each sponsor or sponsor role contributes to the overall business value of Information Technology, only agile and disciplined business applications that satisfy specific organizational needs contribute real value. Thus, providing a clear vision of the business application need is often seen as the most important role of the sponsor. It is certainly the foundation of the test that will be applied in judging the success of any IT project. Still, it is important to not lose sight of the other four.

At first blush, agility and discipline seem to be conflicting goals. In Agility and Discipline Made Easy by Booch, Jacobson, and Rumbaugh, agility is “the ability to respond to risks rapidly; changing requirements or stakeholder needs, or other changes impacting the application we are building.” Discipline for the purposes of this discussion is adherence to the IT principles, architecture, and infrastructure discussed previously. In other words, while the previous requirements may restrict the options available to use, we must chose from the remaining ones creatively to produce the result with the greatest business value.

What if you found yourself managing a project to create a new business application and a senior manager, possibly one of the project sponsors refused to allow you to confer with the prospective users of the program you are to develop and deploy in an effort to elaborate on its desired features and processes? We frequently encounter such gatekeepers who profess to know all that is to be known about the business process being automated. Without this input your business process analysts will be greatly hindered in their attempts to define the use cases for a successful application. At the very least, users will be less likely to adopt the final application as readily as they might had they had the opportunity to contribute to its development. What would you do?

IT Investment and Prioritization

Top-performing organizations have explicit guidelines to help them decide:

• How much to spend on IT.
• What to spend it on.
• How to prioritize IT spending.

Some project managers participate in the initiation of the project and find themselves with an approved project or one bounced back for a better business case or more information. Worse yet, they may simply find themselves in limbo. Others do not come on board until a project is chartered and these decisions have been made. However, even after a project is chartered and well underway, all project managers are advocates for continued funding.

The authors of IT Governance report that a leader of a $15 billion retail enterprise told them, “IT investments are like any other investment. You must make a decent return or you go bust. It just happens faster with IT.” Thus, most project managers attempt to justify costs, especially increasing costs by balancing them against the potential return on investment (ROI) of a project.
When approaching a project sponsor to discuss ROI, most project managers make the error of justifying their costs as they related to the potential value of the system or product they are producing. In fact, project sponsors calculate it against all costs that may be incurred during the product/system life-cycle of which your project is but one phase. Furthermore, it is unlikely that you are privy to all the facts that the sponsor is considering.

What if you found yourself managing a project that was going to cost more than the sponsor was prepared or authorized to approve? What would you do?

Conclusion

Most organizations do not have well-known policies regarding IT governance and the roles enumerated above are not explicitly spelled out. Top performing organizations do. Gently ask any two or more key people where you are working about these five roles and who is responsible for them. If you receive two or more different sets of answers, your project may suffer one or more of the following problems:

• It may be canceled or deemed unsuccessful even if it is delivered on-time and on-budget.
• The product or system created may not be deployed or adopted regardless of the fact that it is accepted by one or more sponsors.
• You may not be able to circumvent gatekeepers who prevent you from accessing the resources you need to accomplish your tasks.
• Worst of all, you may find yourself fighting in court over disputes arising out of your contract.

In each of the foregoing examples, some might ignore the problem thinking that is the sponsor's problem whichever role the sponsor is playing. However, it would remain a risk to the ultimate success of the project and, in all likelihood, you would be branded with the project's failure if it came to that. Far better that you seek a resolution to the problem. It may be a simple misunderstanding on your part that the sponsor can clarify. If a misunderstanding on the part of your sponsors, they should resolve it before you expend their resources on a destined failure in which case you will be far more likely to be called to manage future projects.

Your project can succeed only if it is a success to all sponsors or whoever plays in all five roles. Thus, if you find yourself managing an IT project at a top performing organization count yourself lucky. If not, you have another task to add to your project; helping them define their IT principles, architecture, infrastructure, and investment and priorities as well as their business application needs. You may even find yourself revisiting the project contract or charter before you begin. In either case, you must respond to the needs and concerns of all five for your project to be a true success.

About the Author

Jack Durish is the Interim IT Executive. He has almost 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.

Jack has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.
Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.

Visit his website at http://www.ironlantern.com/

Why Do IT Projects Fail?

Let's be honest. You've known a few that have failed. The GartnerGroup estimates that 30% of IT projects never come to a fruitful conclusion. Depending on how you define “fruitful conclusion” others have set the failure rate much higher; as high as 85%! Gartner further estimates that an average of 51% exceed their budgets by 189% while delivering only 74% of the targeted functionality. That's pretty grim results and we can only expect that they will be worse in a challenging economy.

If you GoogleTM “Why do IT projects fail” you will find links to “The Top Ten Reasons,” “The Six Key Reasons,” and ten million more expert articles and essays on the subject. You will even find advice on how recognize and kill a failed project. But I believe that there is one reason that underlies all those listed; one cause at the root of them all.

The Root Cause

Most projects fail because they lack adequate buy in when they commence or the project manager fails to maintain it throughout the life of the project. I am using “buy in” in the colloquial form meaning “support.” With adequate support most of the reasons attributed to project failure are mitigated or avoided all together. Without it almost any reason will serve to kill a project.

It is not enough to simply have buy in; you must get the right people to buy in.

Who Governs IT?

I would never attempt to sell anything, any service or any product to any organization without first learning who governs IT. Neither would I attempt to manage any project there without this vital information. Too often a project is sold to the wrong people and when the going gets tough, the project is killed by those who should have been consulted first but weren't.

Asking may not help because few organizations have well-defined IT governance roles or, if they are defined, few in the organization know them. Sorry, it's true.

Successful project managers must get buy in from all those who govern every aspect of their project:

• IT Principles – how IT is used in the business
• IT Architecture – how IT is standardized and integrated
• IT Infrastructure Strategies – the people and equipment that supply IT
• Business Application Needs – the source of all IT value
• IT Investments – focusing IT investments on strategic priorities

Even with proper buy in at the inception of a project, the project manager must continually cultivate it. This is especially true in a challenging economy.

Maintaining “Buy In” in a Challenging Economy

Maintaining support for a project in a challenging economy is the same as any other time; it's just more important now than ever before. The rapidly shifting fortunes of organizations in a challenging economy will simply cause shifts in support to and from projects to occur more rapidly. Thus, it is especially important for project managers to keep their projects in full view at all times.

This may seem counterintuitive to some project managers. Many try to hide when the budget axe is being wielded. That tactic may have worked before when company coffers were flush with cash and credit. But, nowadays, you can run but you can't hide.

The best way to maintain interest in your project and support for it is to celebrate milestones. That's right; celebrate them! Make them more than a signature on a deliverable or a high level meeting. Use them as an opportunity to pass out the “attaboys” and remind stakeholders of the value of their investment.

Do not hide budget overruns. Use Earned Value Management to predict budgetary needs so that you can use milestone celebrations as opportunities to campaign for added resources while everyone is excited about your project.

About the Author

Jack Durish is the Interim IT Executive. He has almost 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.

Jack has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.

Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.

Jack now helps executives better understand and perform their roles and responsibilities as sponsors of successful projects.

Visit his website at http://www.ironlantern.com/