Improving project inception by enhancing the supplier-customer integration
Most failing projects are destined for that fate long before assigning a project manager. Their doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. The actual inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could....” From that point forward, the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradigm.
Progressive companies are moving to models that address this deficiency by various levels of supplier-customer integration. These models address improving how to relay information and maintain stakeholder alignment. This drastically changes the project manager’s role to one of a visionary leader—one that ensures that an organization’s strategic and project goals are always aligned. This paper will introduce three methods of improving alignment. The simplest form, improving the documents that describe the project can be implemented at little cost or disruption of the organization. The second, implementing a guidance team, requires a small group of dedicated resources to help the customer through their inception process. Lastly, a new organizational structure is suggested for information technology groups that integrate the project teams with the customer. These varying levels of improvement create a roadmap for an organization’s continuously improving how projects start.
Exhibit 1. Proposal structure
Avoiding Problems That Lead to Troubles Projects
Many actions can help projects avoid trouble. An experienced and detail-oriented project manager who follows a methodology that matches the project’s goals and who communicates with managers will get most projects started in the right direction. However, improving the definition of the project prior to getting it into the project manager’s hands reduces risk and increases efficiency.
Improvements to Project Proposals, Contracts, and Charters
In the simplest form, improving project performance can be as easy as improving proposals and charter. The process for coordinating the project team and the customer is different depending on whether the project is run in-house or outsourced. When projects are outsourced, vendors submit a proposal or bid and results in a contract and SOW (hereafter referred to as simply contract). Contracts may differ significantly from the customer’s original proposal. Contracts and proposals are negotiated items; there is plenty of opportunity for the contract to exclude a significant number of expectations set forth in the proposal. Since the proposal is widely disseminated among both customers and suppliers and the contract, because of commercial terms, is more restricted, the chances for changes going unnoticed is significant. The result is misaligned team members.
In contrast, in-house projects have a project charter reflecting the customer’s desires. The charter often functions as both the proposal and the contract. It reflects the project team’s understanding of the customer’s needs, but fulfills only a few of the proposal’s functions. The charter also references any proposed items that were excluded based on constraints in schedule, budget, or resources. The project charter and the contract are the binding documents for the project.
Proposals need as much detail as possible, and the recommended charter must be more detailed than most standards organizations define (Project Management Institute [PMI], 2008, p. 351). This sets the tone and anchors the business’s understanding of what it is getting. Exhibit 1 outlines the charter’s baseline content.
Be clear in these documents and avoid repeating deliverables; doing so will create conflicts and errors while editing. State what is being provided and refrain from listing out-of-scope items, which, in reality, are infinite. Itemizing nondeliverables only leads to confusion when an anticipated item is in neither the inclusion nor the exclusion list. The only items that should be on an exclusion list are items specifically requested by the customer that the supplier will not be delivering, in other words, they are no-bid items. Experience teaches that when the customer anticipates something without specifically requesting it, and it is missing from the exclusion list while other unrequested items are included, the customer argues that the anticipated item is in scope.
Define the methodology, whether it is a big-bang deployment, critical chain, phased, agile, or some combination. For phased or agile, present the projected releases in a work breakdown structure (WBS). State the reasons why the methodology is required and, if someone overrides it, document the reasons and the impact on the schedule and risk. There must be an impact; otherwise, the suggestion had no foundation.
Most proposal and project charters omit the WBS component; however, it is essential because it outlines the required work and responsible parties. It also sets expectations on the steps required, deliverables, mid-project approvals, and team relationships. Exhibit 2 shows the minimal data required for each WBS sheet. This detail is often left for later in the project’s definition phase (PMI, 2008, p. 116). Although it will be refined and superseded by subsequent documents, these set the tone for the project and reduce surprises.
Since a major source of project failure is scope creep, the WBS should include concurrent approval of design and acceptance criteria, such as IT’s functional specifications and the acceptance test scripts. There are two advantages to this:
- Creating the acceptance documentation helps engineers perform a sanity check on the design specification.
- It helps provide Agile’s close tie of translating design information into tangible product.
This requirement is absent in agile projects because each iteration provides this function.
Exhibit 2. Required WBS fields
The incentive is that most customers have a difficult time understanding the implications of a design specification; they have a much easier time understanding the flow presented in acceptance documentation. This is the result of the acceptance documentation’s step-by-step format. This helps the reader visualize the product’s usage, functions, and boundary conditions. This avoids arguments about the meaning of the design specifications. Releasing these documents at different times leaves the project open for expensive and labor-intensive changes late in the project. It is best to handle this risk early.
Modifying proposals or charters after publication creates the opportunity for setting inappropriate expectations. Keep these documents under strict configuration control. This is especially challenging in outsourced projects, because the involvement of purchasing can inject significant changes to the proposal’s intent. This can leave many stakeholders feeling they are getting something very different from what they anticipated.
Customer Inception: When the Project and the Problems Really Start
Projects start going bad at inception—the customer’s inception. From this point forward, customer expectations are set, dreams envisioned, and compromises negotiated. The initiative proposal process is usually part of an annual planning process. The individual business units gather for planning meetings with their wish lists of initiatives. Through a winnowing process, a few select projects move forward. Others are postponed or rejected. The controlling factors are budgets, resources, estimated value for the business, and strategic and tactical goals.
Exhibit 3. Advantages of a guidance team
By analyzing the characteristics of postponed projects, the supporting organization better understands the customer’s direction. Using this information helps the project team address issues with design, cost, and technology. For example, if the long-term goals of a business include allowing client visibility into the company’s workflow (i.e., allowing the customer to see where a request is in the company’s process), then the initial systems allowing clients to update their demographic data should be very robust. The proposal might even include prototyping future technologies. On the other hand, if the long-range goal is outsourcing the entire system, a simple disposable solution is a better utilization of resources. In short, including the project staff in the customer inception process will provide clarity to the roadmap. It provides a dimension to the “what” and “when” by adding the “what after that.”
Using a Guidance Team to Smooth Project Start
The problem is that these are initiatives rather than projects. Managers often fail to include the implementation professionals in these early meetings. To improve project inception, assemble a guidance team to participate in the business planning meetings and provide oversight and monitoring throughout the project’s life cycle. This will ensure the project team stays close to the intended baseline.
People are enamored with technology—it is the Holy Grail. They accept the limited information provided by sales material as definitive and ignore the hidden complexities in the implementation. As a result, during the early stages of defining the initiative, customers use buzzwords and concepts they believe they understand and make assumptions about the idea’s implementation.
Exhibit 4. Guidance team task
Correcting this is the responsibility of the guidance team. This team consists of two or three people with architecture, product, and project management skills, who stay with the project from customer inception through deployment. Members guide the project teams, set direction, and perform audits rather than working on the projects. Among other things (see Exhibit 3), its members minimize speculation on the initiative’s implementation details— assumptions that bias the product’s definition. The guidance team redirects the conversation back to what is needed and away from how to build it. By assessing the level of complexity in the product, team members help set early and realistic expectations. It removes the opportunity for the customer to conjure up infeasible or overly expensive solutions. Thus, the guidance team helps the customer that knows what it wants create the definition of what it needs.
Understanding the reasons behind the decisions also enables the team to see any incongruities in the project. This is especially helpful as the team thinks about the solution’s robustness or potential workarounds. Exhibit 4 summarizes a number of tasks performed by the guidance team. Thus, when the project reaches a point of someone saying, “I thought we were going to…”, the guidance team will have the background and knowledge to address the question and maintain direction.
Vendor Guidance Teams
The concept of a guidance team is difficult for many companies to understand and objections will abound (see Exhibit 5). For organizations considering outsourcing the project, the feeling is that using potential vendors as a guidance team will bias the proposal in favor of the supporting vendor. This may happen, but reputable firms will note this. The liability of a biased definition is better than having a definition that fails meet business needs.
Internal Guidance Teams
Captive shops simply seem to overlook the option of including delivery personnel, possibly because of the feeling that the engineering organization should be removed from business’s plan development and prioritization. Rectify this perception, as early involvement in the project is invaluable.
All too often, senior management is involved in the early phases of initiative planning and, although this information is perfectly understood, it is inaccessible most team meetings—a requirement to seeing if the project is adhering to its intent. A guidance team can do this. Its members have access to the teams building the solutions and must allocate part of their time to providing steering and auditing functions.
Exhibit 5. Objections to a guidance team
Improving Information Technology Participation in Projects
Information technology organizations continually struggle to build systems that meets their customer’s needs. They tirelessly develop solutions that are delivered late, difficult to use, and deficient in key features and functions. This is not a recent phenomena; it stretches back to the first systems developed. Fredrick Brookes eloquently underscores this in his recount of the 1960’s software engineering project to develop the IBM 360 in his book The Mythical Man-Month (Brooks, 1975). For the chief information officer to solve this problem takes a new approach, one, nearly opposite from today’s direction.
Business Versus Project Constraints
As with many solutions, rather than experimentation, look for the answer in observation. End-user computing, the oft considered anathema of information technology professionals, provides the hint. This group of business geeks constructs what information technology groups appear incapable of building. Using end-user tools like the MS-Excel® And MS-Access®, they create applications that automate and streamline their business’s flows. Unfortunately, these systems are frequently lacking the robustness required in an enterprise. End users are generally lacking the tools, training, and experience to detect those flaws until there is need for integration with other applications, multiuser access, or restoration of lost data. The common answer—moving the application to Information Technology and rewriting it to handle the enterprise requirements—is accompanied with huge capital expenditure, frustration from languishing in the development queue, and significant ongoing maintenance expense. The author has seen this scenario repeatedly in organizations around the world, achieving identical results—a dissatisfied customer. This answer needs to be rethought. If the user is better at creating useful applications and information technology builds better infrastructure, then create an organization to mimic that model.
Like “The” Business
The mantra of the past is to run Information Technology like “a” business. However, the unintended consequence distances Information Technology even farther from the customer. Information Technology should not be run like “a” business, but, rather like “the” business, aligning to their goals, understanding their pain, and rapidly responding to their needs. To achieve this, information technology’s business analysts, developers, quality assurance, and project managers must be placed in the business unit.
Architecture and infrastructure should remain collocated and used as shared resources. This ensures Information Technology’s foundation is solid and it can respond to the business. This core information technology group needs to focus on providing a robust backend that will accommodate the customer’s strategic plans. They provide the adhesive glue and support for the business’s initiatives.
Author of multiple books including, Agile Project Management, Jim Highsmith (2010) explained how he approaches the problem using the agile principles. He points to the solution of how quality and value relate to the traditional triple constraints. In this article, the combination of the triple constraints, value, and quality is the business constraints. The project constraints are a subset of these overall business constraints (see Exhibit 6). Applied to the model mentioned previously, the business is responsible for the information technology supplied project teams. Project success is measured by balancing value, quality, and the triple constraints.
Exhibit 6. Project and business constraints (Adapted from Highsmith, 2010)
The concept of the information technology project has vanished; there are just projects using information technology resources. The business owns ensuring the value, the architect owns the quality (robustness, reliability, technical debt, extensibility, etc.), and the project manager must tune the triple constraints to meet the quality and value needs. This creates a new paradigm for managing project where the focus is not a tactical scope-schedule-budget, but includes the strategic components of value and extensibility/quality.
Exhibit 7: Divested Project Teams and the Relationship of Portfolio Planning and Management
Since most IT organizations service numerous business objectives, it needs to maintain the optimal architecture to achieve all the business’s strategic goals. This is accomplished by providing the means to complete the project, including the technical resources and the architecture.
Project teams, resident with the business (Exhibit 7), have a much clearer picture of the needs; hence, they focus their efforts on tuning the triple constraints to provide value.
Accountability resides with the business, where it should. All team members are responsible for designing and building applications that address problems, and IT provides the tools and resources to create those applications in an enterprise worthy manner.
Challenges With Implementation
The challenge is maintaining a common direction for the IT resources and ensuring an adequate pool of skills to match the company’s strategic goals. This requires frequent training that is aligned with the business’s strategic roadmap, strong IT governance, and strong leadership to guide a distributed IT organization. This starts with a CIO. He or she needs to foster superlative communications throughout their ranks, wherever they are located.
Getting Closer to the Customer
Collocation of engineering and customers is one of the key attributes of agile—the people building the product and the customer or end user are sitting together and the customer directs building a value-laden product. The teams building the solutions are intimate with the customer’s needs.
Finally, this drastically changes the portfolio planning and management processes (see Exhibit 7). This group is more relevant because they pertain to the entire organization. Having enterprise visibility and authority allows this group to prioritize projects, validate their value, identify which are viable and, if trouble arises, which to abandon.
Project expectations are first set at inception, long before the project’s supplier is aware of the pending project. From that point forward, projects are being set up for failure. Numerous actions can be taken to improve this issue. These include expanding the content of project proposals and charters, implement guidance teams, and imbedding projects teams with the customer. This all help align expectations throughout the delivery organization.
Brookes, F. (1995). The mythical man-month. Boston, MA: Addison-Wesley.
Highsmith, J. (2010, November 14). Beyond scope, schedule, and cost: The Agile triangle. Retrieved from http://www.jimhighsmith.com/2010/11/14/beyond-scope-schedule-and-cost-the-agile-triangle/
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide) (4th ed.). Newtown Square, PA: Project Management Institute.
Williams, T. C. (2011). Rescue the problem project: A complete guide to identifying, preventing, and recovering from project failure. New York, NY: AMACOM Books
Williams, T. C. (2011, May 16). The progressive CIO’s model for project success. Retrieved from http://ecaminc.com/index.php/blog/59-generalblog/249-2011-05-16
Williams, T. C. (2011, May 23). I want a shining new PMO, too. Retrieved from http://ecaminc.com/index.php/blog/59-generalblog/250-2011-05-23
© 2011, Todd C. Williams
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas, TX,