Assembling the right teams for systems improvement projects

By Peter Meyer, Principal Consultant, Elkera Pty Limited

5 August 2025

A couple of years ago, I observed a familiar scenario: a medium-sized organisation undertaking a software project with structural problems embedded from the outset. In that case the organisation was undertaking a SharePoint-based intranet project, but the lessons could apply to any systems improvement or software procurement project.

The goals were vaguely stated as: “make all organisational information accessible”, even though the organisation had several core business systems that would not integrate with the intranet.

The project was driven by the IT team and some other senior executives without a clear business case or defined requirements. Not all affected business units were represented on the leadership team.

The leadership team expected the contracted developer to define requirements in consultation with system users. The leadership team chose a group of junior “champions” to help define requirements, assuming they’d be tech-savvy and have time to contribute. However, those junior staff members lacked the knowledge and experience to explain or represent business needs.

Predictably, the project ran over schedule and delivered little of value. The contractor delivered a basic, vanilla intranet product that did little to help users in their day to day work.

So what was wrong with that project?

Unfortunately, the project was unlikely to succeed due to structural flaws embedded at the outset. There was no clearly defined statement of business need and no business case. There was ineffective governance. There were no real requirements. The process of requirements discovery was outsourced to the system developer with the help of enthusiastic, but junior staff.

In summary, the organisation had not structured the project to deliver business value and it had no way to ensure that the developer delivered a product that would provide business value.

In my observation, this is a common pattern. I consider it to be the core reason that many software projects fail.

In this article, I discuss how you should assemble the right teams for a systems improvement project to ensure that the project succeeds and delivers real value to the business.

The focus of this article is on medium-sized organisations where:

The undertaking is for a systems improvement project, not a program or portfolio.
The project scope covers multiple, separately led work areas.
A consultant analyst will be engaged (the organisation does not have senior project management and business analysis skills in house).
A SaaS or customised software solution will be provided by an external supplier.

1. Requirements development should not be outsourced to a solution provider

Requirements definition should not be outsourced to solution providers. Most software solutions in medium-sized businesses are software as a service (SaaS) or are based on existing products. The interest of solution providers is to minimise work and align requirements with the capabilities of their existing product. It is unlikely they are remunerated or motivated to fully understand your business and its real needs.

Requirements must be developed by the business, with expert assistance. The requirements must:

clearly define the expected business outcomes, and
provide a means to validate that the solution delivered by a solution provider aligns with those expected outcomes.

2. Define project purpose and scope

There are various terms for this: project charter or vision statement are common. The minimum elements are:

The project executive or sponsor, ideally the CEO or COO in a medium-sized organisation.
A clear statement of the business problem and need that is to be addressed by the project.
Project scope, covering the key systems and stakeholders.
The expected benefits.
How the benefits will be assessed.

There must be a business case if a systems improvement project is to proceed.

The project charter will be assembled by the initial proponents of the project with assistance as needed. If the technical issues are not understood when the charter is developed, it is very likely that there will be some change to the scope once those issues are factored in. For example, there may be a desire to integrate a proposed system with existing software. That may or may not prove to be feasible.

The project charter must identify all affected business functions and systems. This is essential to ensure that all relevant stakeholders can be identified.

3. Identify all stakeholders

A common problem with project charters in medium-sized organisations is that those organisations often operate under a siloed structure. Projects are developed to serve the ambitions of a particular group. Key stakeholders may be overlooked, or even deliberately excluded in the mistaken belief that it will minimise complexity. That is a critical issue that must be addressed in the project charter and in the composition of the governance team.

Once the project scope is defined, all relevant stakeholders must be identified and included in project planning. The stakeholders to be identified at this stage are those who will form the two teams described in the next section.

4. Two distinct teams are needed for systems improvement projects

Every project needs two types of teams, one for governance and the other for requirements. Confusing the two, or failing to structure either correctly, leads to almost inevitable failure.

In medium-sized organisations, it is common that senior managers will be members of both teams. That can make it appear that there is just one team with variable membership in relation to requirements definition activities.

It is critical that the two teams are actually distinct so that the governance team provides the essential strategic ownership and oversight to ensure that the needs of the organisation as a whole are addressed and there is continuing business justification for the project.

These teams are described in the next sections.

5. The governance team: Strategic ownership and oversight

5.1 Responsibilities of the governance team

The purpose of the governance team is:

Set the project objectives and scope
Oversee the business case
Approve funding and other resourcing
Provide leadership to drive necessary change
Engage and supervise external help
Review and approve project outputs.

The governance team (project board) is accountable for the success of the project and provides direction and oversight throughout. (PRINCE2® Manual, AXELOS)

The governance team may be called the project board or the project steering committee. I will use “governance team” in this article.

5.2 Governance team composition

For most medium-sized organisations, a workable approach to determining the composition of the governance team is described in Table 1.

Table 1: Composition of project governance team

Role	Description	Notes
Core members (decision makers)
Project Executive or sponsor	Owns the business case and strategic alignment. Ensures that resources are allocated.	Typically the CEO, COO, GM or relevant Director. If the project spans several business units, the executive should be the CEO or COO to ensure fair treatment of all stakeholders and to give the project authoritative weight.
Senior internal stakeholders (departmental heads)	Senior representatives accountable for operational teams.	Must understand day-to-day operations and needs of the represented teams but do not need to be subject matter experts. Collectively, they must represent all affected users.
Product or service delivery leadership	For projects involving changes to product or service delivery to customers or other external stakeholders, the executive responsible for customer satisfaction.	Must understand the business objectives for the proposed changes. Ensures that the customer perspective is understood.
Internal advisory and support members (not decision makers)
Convener or Coordinator	Manages logistics, follow-up and documentation for governance activity.	May be a project coordinator or EA.
IT director	Advisor	Provide advice as needed regarding current capabilities and implications of change proposals.
Legal or compliance director	Advisor, if required.	Provide advice as needed on compliance and procurement issues.
HR director	Advisor, if required.	Provide advice in relation to staffing changes.
External advisory and support members (not decision makers)
Consultant Analyst	Advisor who participates by invitation only.	Advises on problem definition, leads requirements discovery and development of solution options. Assists or leads business case development as required. Also participates to align delivery of services within contractual commitments.
Senior supplier	Advisor who participates by invitation only.	Participates to plan solution delivery to align with contractual commitments.

5.3 Key points about the governance team

The project executive or sponsor is a critical role. It is one person. The executive must be sufficiently senior to make decisions about the project, based on advise from other members of the governance team. The executive must be able to allocate resources to the project.

To ensure that the interests of all stakeholders are adequately taken into account, the executive must not be one of the senior internal stakeholders.

The executive must devote sufficient attention to the project to be able to make effective decisions and to ensure that all stakeholders take the project and the governance structure seriously.

6. The Requirements Team: Understand the problems and define the business needs

6.1 Responsibilities of the requirements team

The requirements team is responsible for:

Understanding business problems and objectives.
Discovering and articulating user needs, constraints, and workflows.
Developing ideas for improvements.
Assessing the business value of proposed changes
Validating proposed changes with affected stakeholders.
Producing structured, prioritised, and reviewable requirements (functional and non-functional).

This team works under the direction of the governance team with process and creative leadership provided by the consultant analyst (or internal analyst, if available).

Outputs from the requirements team work are developed by the consultant analyst and validated by relevant members of the requirements team before submission to the governance team.

6.2 Requirements team composition

The core requirements team members must be process experts. The broader requirements team may not have a fixed composition. Personnel with relevant expertise will be consulted as needed.

A basic requirements team structure is described in Table 2.

Table 2: Composition of requirements team

Role	Description	Notes
Consultant analyst	Plans and facilitates the requirements process. Runs workshops, challenges assumptions, develops documentation and validates results with team members.	Primary driver of requirements activities, including proposed changes. May also advise on solution feasibility.
Senior users	Provides deep operational knowledge and insight into processes. Consulted by the analyst and ensure that the analyst understands current processes and problems. Could be a member of the governance team.	Available users must cover full workflows, not just discrete areas. Senior users validate proposed requirements. See section 6.3.
Line managers	Ensure that requirements align with actual processes and performance objectives.	Required to validate business efficacy of proposed requirements. May be involved in reviews or selectively in workshops.
Front-line users (selected)	Consulted as needed to provide explanation and insights on specific processes.	Consulted only, not decision-makers.
IT advisor (optional)	Helps assess technical feasibility and internal systems implications.	Ensures requirements are technically informed. Does not drive process or requirements decisions.

6.3 Key points about the requirements team

Identification and definition of requirements is a change process. The consultant analyst ensures that the requirements are coherent and aligned with the business needs. The consultant analyst elicits knowledge, not opinions. Senior and other users may have ideas about improvements to existing processes but do not determine requirements. Often, senior users need to be challenged to look beyond existing approaches during requirements definition.

The consultant analyst must lead the requirements team so that, at the end of the process, senior users and line managers can recognise the need for change and assess that the requirements reflect real business needs.

Requirements must cover the full extent of relevant workflows, not just the processes of specific work units.

Requirements for SaaS and customisation projects must define business needs without being overly prescriptive about how those needs will be addressed. Requirements for SaaS projects are discussed in my article: Why SMEs should define software requirements before buying a SaaS product.

6.4 Relationship to governance team

The requirements team executes the discovery of requirements in accordance with the authorisation provided by the governance team.

The consultant analyst bridges the two teams.

7. Warning signs your team is misaligned

Many medium-sized organisations lack the structures to manage internal change effectively. The result is often unclear goals, misaligned teams and limited value delivered. Organisations that do not have well developed processes for change planning may miss important elements in the project structure.

Table 3 lists common symptoms of unsatisfactory project structures that will almost certainly lead to the project failing to deliver real business benefits, or failing outright.

Table3: Common warning signs of defective project structure

Symptom	What it suggests
Unclear business objectives	Governance failure with insufficient attention to defining business problems and the business justification for the project.
No committed project executive with overall authority	No accountability and low or zero commitment by some stakeholders. The project may be highjacked by one work unit leader.
Consultant is determining project scope	Governance team is not functioning.
Junior staff selected for requirements team	Shallow, low-value requirements.
Solution vendor is responsible for requirements elicitation	Requirements will be shallow and likely will not reflect the real needs of the business. Requirements are likely to be aligned to the solution offered by the solution vendor.
IT driving project scope	Tool-focused instead of business needs-focused.
No cross-functional view (incomplete teams)	Requirements reinforce existing silos.
No requirements validation plan	Requirements may not be aligned to business needs.
Vague or unfocused meetings	Inadequate governance and inadequate planning by the consultant analyst.

8. Conclusions

The success or failure of most business process or system improvement projects is largely determined before any work begins. To be successful, a project must have well structured governance and requirements teams with the right people in the right roles.

The governance team must actively exercise ownership and ensure accountability continuously over the duration of the project.

The requirements team, led by the consultant analyst, must fully understand the current state of the business and develop practical requirements that will deliver clear business benefits. Effective requirements definition requires active input from senior users with deep operational knowledge.

Requirements definition must be undertaken before engaging solution providers.

Before starting any project, take the time to confirm whether your governance and requirements structures are fit for purpose.

Download a project set-up checklist

To assess your project readiness, download our free project set-up checklist.

Project set-up checklist.