Blog
Poorly Defined Project Boundaries Lead to Project Failure
Many organizations continue to deal with the daunting problem of failing projects. Over the past 10 years, there has been numerous studies on the problem of project failure. Yet, project performance has not improved. See a few surprising recent statistics.
- Over 1 in 3 (34%) projects have no baseline. (Source: Wellingtone)
- For every $1 billion invested in the United States, $122 million is wasted due to lacking project performance. (Source: PMI.org)
- Less than a third of all projects completed successfully on time and on budget. (Source: Standish Group)
- 75% of business and IT executives anticipate their software projects will fail. (Source: Geneca)
- 75% of IT executives believe their projects are “doomed from the start.” (Source: Geneca)
- 33% of projects fail because of a lack of involvement from senior management.
Project Failure Symptoms
Projects continue to run over budget, behind schedule, produce poor quality, or just do not meet the intended objectives. Implementing project controlling strategies, consulting project management experts and leveraging new development methodology approaches (i.e., SCRUM) has not solved this problem. Why are we still failing?
Below are 10 examples of reasons given as to why the projects fail.
- The business case, scope, deliverables or requirements were poorly defined
- The project was forced to start execution without proper planning
- The project expectations, success metrics and objectives were never defined or accepted
- The project was understaffed, under budgeted, or missing critical skills roles
- There was a lack of user input and active participation from stakeholders
- The project’s scope, requirements and priorities keep changing
- The leadership and key stakeholder never bought into the project
- Project baselines, change management and quality assurance standards were not set
- The project team did not understand the business needs and requirements
- The technical lead/resources did not have the right technology skills
Although all these reasons have some validity, they do not truly address the underlining reason why the project failed. Most cited reasons for project failure are really symptoms. Instead of dealing with symptoms, organizations must begin to address the contextual issue. Contextual issues are complicated by the increasing ambiguity in which most projects operate.
Project Boundaries
One critical contextual issues is the overall lack of understanding of the project’s boundaries. Project boundaries are the guidelines, rules and limits that are defined to determine the reasonable and acceptable environment in which the project will operate and how the project should respond when something happens to take it outside of those limits. Project boundaries aid with establishing success measure by defining what is in the project, what is not in the project and when the intent of the project has been met.
Setting of project boundaries is a business contextual exercise that requires defining the overall business strategy and aligning that strategy to the project outcomes. Establishment of project boundaries must be completed prior to starting project activities. Project boundaries are critical inputs to the planning process.
Below are key project boundaries that should be established in order to increase the likelihood of project success from the start.
-
- Business Strategic Objectives. When defining business strategic objectives, the activity should include the project sponsor, project governance, critical project stakeholders, business and technical architects and the project management expert. The objectives should clearly layout what the business is intending to achieve through the project. These objectives should be tied to project’s results, outcomes and/or deliverables.
- Project Scope Description. A short description that lay out the deliverables (functions, features, components, and documents), outcomes and outputs of the products, services, and results of the project. The scope should be socialized and finalized with the key stakeholders. Any changes to the scope, should result in an assessment of all the project boundaries to determine if realignment is required.
- Minimum Success Criteria. Defining project’s success criteria establishes what total success looks like. However, this initial list can get very long and be full of assumptions. This list should be narrowed down to the minimum success criteria. The minimum success criteria represents the smallest outcome that is acceptable to deem the project a success at meeting the critical business objectives. Having this will take the guesswork out of understanding at what point the project has truly failed.
- Organizational Assumptions and Constraints. Organizational assumptions and constraints should be described at the start. These should not be left for the project team to discover on their own. For example, if known that the project’s new application must reside on the existing infrastructure due to security requirements, then this should be called out upfront.
- Project Management Policies. Projects typically have to adhere to a number of policies and controls. Having a clear understanding of what they are and what types of constraints they will put on the project will reduce the number of roadblocks. All governance and compliance groups should be consulted so they may aid with defining the policies that will govern the project.
- Communication and Engagement Objective. Early communication and establishment of engagement rules can significantly reduce the confusion and frustration during the project. If there a multiple stakeholders or conflicting needs, establishing a business representative that will serve as both a liaison and referee is a great option. This removes the project team from the politics and assigns someone directly with the responsibility for keeping everyone aware and involved at the correct levels.
- Roles, Responsibilities and Authority. Knowing external roles, responsibilities and authority lines enables the project team to receive quicker decisions and increases probability that the information received is accurate. It is critical to define authority clearly. Titles and roles do not always equal authority.
Carla Griffin, BSC, MPM, PMP, ITIL, COBIT, has over 18 years of Analysis and Project Management experience in various industries (Government/Public Health, Financial Services, Information Technology, Claims Processing, and “Big 10” Consulting).
The Critical Role of the Analyst in Projects
When assessing trouble projects, the first area I evaluate are requirements. A major red flag is the underutilization of analysts. There is a growing trend within in IT organizations to limit the role of the analysts to meeting scribes, technical writers, and trainers. This approach misses out on the true value a great analyst brings. If integrated fully into the project team; a strong analyst can significantly add project team’s ability to quickly delivery value to the customer by increasing the overall efficiency of the team.
Why don’t more teams fully integrate and use analysts? Simple, they don’t know how. Many IT organizations and project teams struggle with how to leverage analysts. This is even more evident in organizations that are strongly rooted in Agile principles. The traditional role of analysts no longer fit cleanly into many of the manifestos, frameworks or methodologies teams are using. As such, without a clear understanding of what analysts are suppose to do, many teams have just opted to remove them all together.
Without individuals within the team that are responsible for discovery, elaboration and alignment activities, most project team quickly find themselves chasing their tails. Proper incorporation of analysts into the project team activities is still very much needed. Below are seven guidelines to consider that may help to maximize the value of the analyst role within your teams.
Guideline #1: Respect the value of the analyst role
With the tightening of funding, organizations are insisting on seeing the return on investments from technology solutions efforts. Analysts are in unique positions to demonstrate this value. Thus, ensuring your project has a clearly defined analyst role is critical. Analysts sit firming between the business and the technology side. In Agile context, team typically deal with the Product Owner to derive the solution vision and define the minimum features. However, often times, the Product Owners is relying on someone to play to the role of analyst for them. These individuals focus on determining the business problem, defining the desired outcomes, and assisting the business with articulating those outcomes into specific functionality requirements leveraged by the technical team.
Even within agile and pseudo-agile software development teams, the role of the analyst is warranted and valuable. Without a strong analyst role, the project team runs the risk of not fully understanding the Product Owner/customer’s problem set. This lack of understanding often leads to ever shifting requirements, large amounts of rework, scope creep, schedule overruns, project team frustrations, and customer dissatisfaction.
Guideline #2: Use the Analyst to analyze and document
Projects are becoming increasingly complex. Many projects start execution without sufficient scope definition. In addition, it is typical for a project to already have a set deadline, budget ceiling and be understaffed. With these constraints, it is critical that someone on the project team be responsible for figuring out what the customer needs are (i.e., requirements, user stories, acceptance criteria, etc., ). Figuring out requirements can take a considerable amount of time which may include reading documentation, researching operational processes, clarifying information with numerous stakeholders and creating documentation. This is where a strong analyst shines.
Guideline #3: Allow the Analyst to relieve pressure on customer
One of the primary complaints from stakeholders is the amount of time projects take away from them performing their “real” jobs. If properly leveraged, the analyst can serve as pseudo-user or proxy Product Owner. Use the analyst to develop in-depth knowledge of the various user job functions, operational processes, policies, procedures and business environment constraints. By stepping into this slot, the analyst can successfully represent the business group and increase time flexibility for the stakeholders. In addition, the analyst is able to provide greater clarification to the technical team about the perceived stakeholder value of developed functionality.
Guideline #4: Allow the Analyst to relieve pressure on project technical roles (developers, architects and infrastructure engineers)
Although, I know a number of developers, engineers and architects that like to work closely with customers around requirements, it is not always the best approach. When dealing with small, maintenance or product feature enhancement type projects where there may not be strict timelines or scope, the Agile developer-customer relationship often works fine. However, for large enterprise or transformational projects, this approach can quickly run off track. No matter how well the intentions, eventually, there is a conflict on the amount of time that should be spent dealing with requirements verses actually developing the system. By identifying an individual on the team who is primarily responsible for requirements management, technical roles on the project can remain focused on what they do best. In order for technical project resources to feel greater comfort with allowing the analysts to take the forefront with the customer, the analyst must understand how to communicate information with the technical side of the house as well.
Guideline #5: Use the Analyst to validate that the project’s vision and outcomes align
When serving in the role of a Project Manager, one of the main things I tend to leverage my analyst for is breaking down the business needs into technical scope functions/features/components. Analysts can provide great insight into what is being asked and why it is needed. Understanding these two things clearly leads to reducing ‘gold plating’ and increasing the likelihood of successful project delivery.
Guideline #6: Leverage the Analyst to support change management
Analysts can be instrumental in controlling change. Analyst tend to become subject matter experts with specific products, processes and systems. This expertise can then be leveraged to identify, quantify, qualify, and prioritize changes. Controlling changes within a project enables the team to focus on the things that create value and will deliver the intended solution. In addition, leveraging analysts to spearhead change control boards after the bulk of the initial requirements gathering is complete is a great value add.
Guideline #7: Use the Analyst to bridge the transition gap between system deployment and operation
A common business complaint at the end of many projects is the lack of coordination between applications development and business operations. Often time, after the new or enhanced system/feature is deployed into production, the project comes to an abrupt end (at least from the user’s perspective). Even in organizations that have established “transition support periods”, this support typically focuses on addressing defects or basic user onboarding. This perceived drop off can leave business users struggling to absorb the new functionality. By leveraging the analyst to serve as the bridge, deployment to implementation transition can become closer to seamless for the users. The analyst can serve as a common face for users and often, if knowledgeable enough, can proactively identify and handle post-implementation transition issues.
Carla Griffin, BSC, MPM, PMP, ITIL, COBIT, has over 20 years of Transformational Program and Project Management experience in various industries (Government/Public Health, Financial Services, Information Technology, Claims Processing, and “Big 10” Consulting).
PM Practical Solutions, LLC 