To understand how technology stakeholders use requirements to solve problems, it is important to understand how project management methodologies are organized. Countless project management methodologies have been developed over the years. Some work well with smaller projects, some work with larger projects, and some are effective with hybrid methodologies. Some methodologies are very thorough and powerful, while others are simple and easy to learn. Although each methodology has its own nomenclature and structure, they all essentially tell the same story. Table 4-3 is a project management meta-methodology diagram that shows the logic that underlies most, if not all, project management methodologies.
Table 4-3. Project Management Phases and Activities
Decide | Plan | Do | Finish | |
|---|---|---|---|---|
Deliverable: Project Charter Result: Go/No Go Decision | Deliverable: Project Plan Result: Approval to Build and Deploy | Deliverable: SDLC Documents Solution | Archive Lessons Learned Life-Cycle Plan | |
What |
|
|
|
|
Why |
|
|
|
|
How |
|
|
|
|
Who |
|
|
|
|
When |
|
|
|
|
Where |
|
|
|
|
What follows is a discussion of the project model described in Table 4-3.
The first phase of any project is focused on gathering enough information to determine whether the project should continue. The first phase is called a number of different names depending on which methodology is used, but its purpose is to decide whether to continue the project effort.
The first phase produces a written document known as a project charter or contract. The project charter is usually written by a project manager at the request of the project sponsor, who is the project’s "owner." Once it is written and approved, the project manager is responsible for managing the charter document. If changes are required after approval, the project manager must obtain approval from the project sponsor to make alterations. This document describes the estimated benefits, costs, and deadlines in sufficient detail to justify further analysis. The project charter is structured as follows:
The front of the project charter document identifies the project, establishes its official name, and identifies the timing, sponsor, and project manager. It may seem obvious to provide an official name for the project, but it is amazing how many organizations generate competing unofficial names for a single project, causing confusion and opportunities for error. The project name on the front of the project charter is the authoritative name for the project. All other names should be discouraged or eliminated.
Listen to the business stakeholders’ story problem. Get the business stakeholders to tell their stories. Don’t criticize them for being vague, don’t argue with them, don’t get defensive. Just listen and ask questions that help the business stakeholders refine and articulate their problems and needs.
The purpose of the high-level requirements is to identify the key features and services that represent the focus of the project’s efforts. Later in the planning phase of the project, after it has been approved and the project charter has been approved and funded, the requirements can be further defined if needed.
To develop the high-level requirements, the project manager works with the project sponsor to articulate which business drivers are being addressed by the project scope. For each of the identified business drivers, the project manager works with the project sponsor to identify five to ten measurable business features and services that will be developed to address the project scope and business drivers.
For each of the high-level requirements, the project sponsor creates a limited number of test or measurement criteria to be used to prove that the requirements are met. It is important to base the test requirements on the business requirements and not the technical design, as is often done, because the proof of the solution will be the degree to which it meets the business needs and not how well it conforms to the technical design. The design is useful only if it helps the team efficiently and effectively meet the requirements.
The business justification is often the most dreaded aspect of project initiation. However, it is necessary to clearly state why the project is being proposed and what the business will gain from its successful completion. To arrive at a meaningful and compelling business justification, the project’s goals must be well understood in light of the business goals and drivers prioritized by the organization. The total cost of ownership must also be taken into consideration so that the project sponsor and steering committee are able to judge the technology investment in terms of opportunities lost, money invested, and resources that are not available for other tasks.
The bottom line in the project initiation process is that the effort should be quickly cancelled if there isn’t sufficient business interest to obtain approval. If the business stakeholders don’t support the project, it will most likely fail. Even if the project team manages to muscle the project to completion, there will be little or no interest in the project and possible resentment over money being spent on technology for its own sake. Technology projects should proceed only if there is a solid business reason to do so. Technology should never be pursued for its own sake.
Having said this, it is also important for the business stakeholders to understand that technology requires continual improvement and uplift if it is to be an effective and agile platform for delivering ongoing business solutions. The business must recognize and support the concept of technology life cycle management where technologies progress through an ordered life cycle and are retired just before obsolescence. This means that the business must support routine maintenance and uplift projects even though they do not necessarily represent a direct improvement in performance or services. Without continual refresh and uplift, the technology environment will be unable to extend to provide new business services and features.
In project management, every decision requires a trade-off between cost, resources, and schedule. If new features are added, cost goes up and the schedule goes out. If the schedule must remain the same while scope increases, cost increases dramatically. It is a best practice to rank the project’s success criteria in order of emphasis. Project management decisions involve making intentional tradeoffs between the three success criteria: resources, schedule, and scope. These three are ranked in order and provide a common understanding that the success criterion listed first is the most important and should be the last to change. The third success criterion is the least important to the project’s success and therefore the first to change if the project must be adjusted. This is also true in business agreements in which the contract may stipulate that cost, or time, or performance is the essence of the agreement. The essence can’t really be all three because a change in one significantly impacts the other two.
As the project progresses, is it more important to guard the cost, timing, or features being developed? Keep in mind that a change in the project goals, schedule, or budget will require approval by the project sponsor and the steering committee, so this ranking doesn’t remove accountability from the project team. It does, however, help the project team keep the primary goals of the project in mind at all times.
The technology strategy identifies whether an existing or new technology is needed to meet the project goals and how the technology will be implemented. Although the purpose of technology is to meet a high-priority organizational need, the development of new technical solutions often presents an opportunity for new technologies or an uplift to existing technologies. Often, the business needs a new technology or service because it is trying to diffuse business pressures that result when rivals gain a competitive advantage by leveraging improved or even disruptive technologies.
So, although the best practice is to drive technology projects from a business perspective, it is also important to invest in new or disruptive technologies to gain an ongoing technology advantage over the organization’s competitors. If the solution is expected to require or facilitate the assimilation and deployment of a new technology base, this should be described in the project charter. This may work against project approval if the new technology is beyond the core skills of the organization. New technology can present a serious risk to project success because it usually requires the development of new skills and integration into legacy technologies. By definition, new technologies are being deployed to bring about a significant change in the technology base of the organization. Significant change increases the chances of unintended consequences and impacts with existing technologies. The results are very difficult to predict in advance. If the project presents an opportunity to extend the technology base of the organization without incorporating significant risk, it may work for the approval of the project.
A project is nothing more than an organized effort by people working as a team. Critical to a project’s success are the individuals who will be engaged in supporting and staffing the project team. The most important member of the project team is the project sponsor, who provides and controls the budget for the project, as well as the project scope and schedule considerations. The project sponsor is, in short, the project’s customer. The steering committee is a team of advisors chosen to support the project sponsor’s decision making. The steering committee is often made up of representatives from various business groups within the organization who have a vested interest in the project’s successful completion. Ideally, they represent a wide variety of viewpoints and backgrounds so that the project sponsor receives feedback and advice from many different perspectives.
The project charter also must provide the stakeholders with a rough idea of the major phases of the project and their timing. From the perspective of the project charter, the major milestones include the timing of the project phases themselves as well as any major deliverables or activities that embody the major focus of the project.
Technical solutions must be hosted in a physical location, the operations support must reside in a physical location, and the user community is located in one or more physical locations. The project charter presents a concise overview of these physical locations and their impact to project success so that the business stakeholders can evaluate the validity of the project. Is the target user community in a closed country or a country not currently supported by the organization?
Does the solution require hosting in a location or circumstance that is outside the organization’s existing best practices? If so, these must be concisely documented and included in the project charter.
It would be unwise to build a house without first spelling out the layout, plan, location, schedule, details, and contract terms of the project. Generally, once the plan is agreed to by the homeowner and the builder, the builder is held to the estimates. However, if the homeowner makes a change to the initial requirements, the builder provides an incremental estimate of the cost and schedule impacts of the changes being proposed. This impact estimate is then submitted to the homeowner for approval. If both parties agree, the contracts and plans are formally amended. This is a legal change process that is binding on both parties. No sane individual would tell a builder to build a four-bedroom home at a certain cost per square foot and leave it to the builder to fill in the gaps in the plan!
Quality and consistency in the housing industry is maintained by an integrated system of standard materials, tools, construction codes, best practices, ordinances, and inspection processes. This common body of knowledge has enabled the housing industry to follow a common strategy to efficiently and economically build homes in a wide range of markets. In general, a power outlet can be taken from one house and installed seamlessly in another house, even if the two are separated by long distances and decades of time. Why are the parts interchangeable? Because the construction teams and suppliers followed common standards and rules.
In a similar fashion, technical standards and best practices give individual project teams the ability to develop solutions independently and quickly while maintaining interoperability.
Requirements are time dependent. Requirements describe a need to adapt the business to the demands of its internal and external environments. The delay between the need for this adaptation and its fulfillment leaves the organization vulnerable to competition, litigation, regulatory punishment, elevated operating costs, and other threats. Good requirements must, therefore, be timely as well as measurable, concise, commonly understood, and change controlled. The systematic use of business and technology strategy documents also makes requirements development faster by focusing the description on what is being added to the overall framework rather than describing the solution requirements from the beginning.
Technology standards and policies require a great deal of maintenance and administrative support. There is an exception to every rule, and the consistent use of technology standards requires that exception or variance requests be consistently evaluated and managed on merit. Even where they provide adequate guidance, the organization’s technology standards rapidly become obsolete and must be constantly refreshed.
The process of creating, reviewing, updating, and applying technology standards is known as technical governance. Governance also includes evaluating and handling exception requests and providing a roadmap showing how the technology standards will evolve over time. This roadmap includes the preferred technologies and standards, acceptable technologies, technologies that have been retired, technologies that are being retired, and future technologies that are being evaluated and are planned to replace the current preferred technologies.
Business process engineering should always be tightly coupled with the technology roadmap because technologies must be used by people in the context of performing their work within the organization. Technology always impacts the business model, and the business model always impacts technology. If the technology doesn’t impact the business model in a favorable way, you should question why the technology is being deployed in the first place.
Best practices are those recommended policies, operations, and methods used to integrate, use, maintain, and update the technologies described by the enterprise architecture and its roadmap. Best practices generally define how systems are built, deployed, and maintained, while the architecture describes which technologies and components are to be used. Taken together, enterprise architecture, business process engineering, and best practices form a very powerful tool for effectively creating repeatable and maintainable solutions to address the needs of the business.
As a result, the technology governance team should include solid representation from the community of business stakeholders. Although the details of the technology strategy are "behind the curtain" as far as the business stakeholders are concerned, the inclusion of business stakeholders in the governance process provides the opportunity to provide an ongoing reality check for the technology stakeholders when choosing solutions and strategies. It also forces the technology stakeholders to think through the standards, best practices, and technologies chosen because they must be explained to the business stakeholders during the governance process. Also, business stakeholders have a remarkable ability to detect bias, meaningless arguments, and other tangents that often distract technology-focused teams. The final major reason to include business stakeholders in the technology governance process is that it raises the business stakeholders’ trust in the technology stakeholders’ thinking and decision-making processes. In organizations where there is no joint governance process, the business stakeholders usually hold the technology stakeholders in suspicion or outright hostility. A collaborative effort involving both the business and technology stakeholders can quickly alleviate this situation.
Just as the technology stakeholders must provide an over-arching technology strategy to keep all of the development projects aligned and to minimize the burden on the requirements process, so must the business stakeholders identify the overall goals of the business.
The organization’s business goals are generally developed in response to external business drivers that have been identified and prioritized by the business stakeholders. Business drivers are the high-level business needs that the business requirements seek to address. Business drivers can include, but are not limited to:
Changes in the regulatory environment. Are there new laws or guidelines being imposed by the government or some set of professional organizations? Are these constraints mandated or just recommended? What is the timetable for adherence?
Changes in the competitive environment. What is the organization’s position relative to its competition? Is its position improving or getting worse? Are there new competitors or new product offerings that have changed the stability of the organization’s competitive standing?
Changes in the market. How has the market changed? Has it grown or gotten smaller? What are the key business drivers impacting the organization’s customers, and can new product or service offerings help the customer meet those objectives?
Changes in technology. Has a new disruptive technology come into play that will destabilize the competitive environment? Does this new technology provide an opportunity for the organization to leapfrog its competition or enter new markets? What is the risk in adopting the new technology? What is the risk in not adopting the new technology?
Changes in personnel. Have key individuals or skills left the organization? Has a competitor gained a recruiting and retention advantage? Has the organization lost its ability to differentiate high-performing and low-performing individuals? Has the organization lost the ability to hold employees and departments accountable?
Changes in distribution. Has the organization’s ability to deliver goods and services changed for the better? If so, how can the organization further capitalize on this improvement and exploit it to advantage? Has the organization’s ability to deliver goods and services changed for the worse? What is the long-term risk to the organization? How can the organization correct this downward trend?
Geopolitical changes. Have disruptions in government, the environment, and other large-scale population impacts affected the organization’s ability to continue doing business? What business continuity plan or activity can be implemented to bring operations back in line with the organization’s normal best practices?