Wednesday, March 18, 2009

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/