Technical Project Resources

Scoping An IT Project – Things To Consider

The information in this guide is intended for general purposes only. For more specific guidance around your organisation’s projects, please get in touch with our team.

In this section, you will find:

Many projects within the private and public sectors are based on the evolution or replacement of systems or other technologies. The scoping stage is critical with all the minutiae involved in IT-based projects. It’s unfortunately quite common for tech projects to run past their initial deadlines and blow out budgets. While it’s not always possible to account for unexpected things happening and impacting the project, a well-defined scope helps put controls in place that guides decision-making and planning that can drastically reduce the chances of wasted time, resources and money.

In this guide, we’re going to explore some of the considerations worth making as you plan an IT project in your organisation.

Managing risks in a project portfolio IQANZ

Get clear on the project deliverables

Building a good scope document is virtually impossible without having complete clarity on the outcomes. If there are no concrete objectives, all the parameters of a project scope document for your IT project will be loose or, worse, inaccurate. Outcomes don’t simply talk to the project’s milestones but the impact on the business or its customers. When the organisation has adequately determined what strategic or operational impacts they’re driving towards with this initiative, the scope becomes more of a matter of translating these outcomes into tangible deliverables and the activities required to deliver them.

Sometimes the business won’t have articulated the outcomes to the level that a team responsible for building the scope can draw from properly. If that’s the case, we’d suggest challenging the leadership team or accountability for that outcome to clarify what those outcomes mean. Having these pointy conversations now is far easier than trying to street a project out of the wrong direction – and costs a lot less.

Establishing functional and non-functional requirements

IT-based projects need to deliver a solution that meets a list of both features and performance attributes. Consider the functional requirements as the list of things that need to be developed to allow the end users to complete their work satisfactorily. In essence, it outlines what the solution does. This list must be comprehensive and help the project team plan out each aspect, phase or sprint. An example of a functional requirement might be ‘the ability to search for a user by account number’ or ‘produce financial reports by date range’.

On the other side are non-functional requirements. These are more related to the user experience and describe the solution’s quality. The functional requirements being developed and implemented properly will have the knock-on effect of meeting these non-functional requirements. Examples can include the response time of the solution, how many users it can accommodate, and general usability metrics such as locating key buttons and information efficiently.

Testing of requirements will vary accordingly – often, the testing of functional requirements will use a set of tools and practices to ensure the code and development is sound. The non-functional requirements often involve non-technical input, notably from end users who can put the solution under typical daily tasks and feedback on the ease and speed of this.

What are the must-haves vs. the nice-to-haves?

Building a scope document can be a bit of a preview of what it’s like as a project manager defending that scope during the delivery stage. That means negotiating with stakeholders about what’s relevant to the core project outcomes and what would be nice but may not be feasible. Part of the scope document may be a prioritisation exercise. It may necessitate outlining a minimum viable product (MVP) state.

With a technology project such as implementing a new customer portal, financial management system, internal communications, security infrastructure or anything else in the IT realm, there are often plenty of degrees to which an implementation can be rolled out. Features and functions of a new system are quite a good project for prioritising deliverables, as specific elements of the solution can be deemed vital or nice to have.

Your scope document should clearly state the parts of the system that are required for it to be considered delivered and meet the requirements for the business objective. Sometimes we suggest that larger projects get split up into smaller ones, each with its own discrete scope, budget and timeline. This can often control the risks around failure due to costs, resources or technology issues. For a tech project, it may be that a phase one project for a system is to get the basic functionality robust, with future projects designed to deliver a version 2 with more of the nice to haves.

Determine the platforms and systems needed

Unique to a technology-based project are the systems and digital tools required to deliver. Beyond the people that understand how to code, design, test and configure your solution, there needs to be a significant review process around the software and hardware required. The scope will often be preceded by a discovery phase in which both business and technical personnel will surface the best tech stack required. Often specialist roles like solutions architects, engineers and others will contribute to this research and provide well-informed recommendations.

The scope document should be able to outline the platforms and systems in the requirements section of the document.

Confirm the skill sets and roles needed to deliver

Your scope document will outline the acceptance criteria, limitations and assumptions, as well as the deliverables required. But it’s important to consider the resources you’ll require to make this a reality. Depending on your business and the project, you may have a significant amount of resources internally that can be allocated to delivery. It’s more common for organisations to combine internal subject matter expertise with contracted IT professionals who bring specific skill sets into the fold. Often IT project managers are brought in on contract as well.

As part of the project deliverables, the project management office and steering committee should develop a set of roles that are required to deliver on each of these milestones. Common skills include back and front-end development, UX designers, testers, security specialists, technical writers and so on.

Working to a set budget

It’s not an absolute rule that the scope needs to provide detailed information about the budget – this may be managed separately. But suppose your scope information is part of a broader project planning document, and it makes sense to have the budget captured in the same place. In that case, connecting the deliverables to budget allocation can be a good idea. Some IT projects may have a split budget for each phase/deliverable which can be a good approach to controlling costs at a more micro level.

The budget must be protected as much as possible. Having a clear correlation between deliverables, resources, time and budget that project managers can proactively track is highly beneficial.

Roles and responsibilities

The governance framework you embed into the organisation or adopt for the project will be where management of approvals, information sources and sign-offs will be captured. But the scope of your IT project will (or should) include a section on ‘Acceptance Criteria’ – that is what are the checkpoints a deliverable needs to go through before considered approved and completed? This usually means that a specific owner in the business needs to have a final sign-off. The scope document should capture who those people are and to what deliverables they are accountable for signing off. There may be other steps before this, such as user testing, but this document must note the final sign-offs.

Determine reporting requirements

Reporting empowers projects and project teams. Reporting shouldn’t be viewed as a necessary evil or admin, but rather a chance to get the wider business (and leadership) across progress. Project managers can use good reporting practices to more accurately estimate project budget and resource requirements, and identify trends that may need to be addressed.

Work with stakeholders, the project steering committee and leadership to determine what information needs to be included in reporting, the frequency and the recipients. There is often a different level of detail for certain audiences – a financial controller will be most interested in the burn rate of the budget as opposed to the fine detail of functionality.

Conduct extensive risk assessment

Embedding a culture of proactive risk management is one of the best things for your project health you can do. Risk analysis is about surfacing all the things that could happen and finding solutions or mitigations to these.

Risks to the project are unique from constraints in that they aren’t things that exist today, but could arise in the future. Risks will typically have certain variables assigned to them such as the likelihood of happening, the severity of impact on the project etc. The actual risk analysis process takes some time and will often be the responsibility of the business’ risk management team.

Risks in an IT project can include security vulnerabilities in the solution, incompatibility between platforms, bugs, loss of access to hardware or downtime of cloud-based applications. A whole stream of risk management roles deals with information technology, bringing together risk assurance methodology and IT knowledge.

Exclusions

Exclusions are core to a project scope’s ability to protect the delivery team and business from inefficiencies due to requests from stakeholders that fall outside the parameters of the project. It’s worth spending as much if not more time on exclusions or ‘out of scope’ as it is on what the deliverables are in scope. Exclusions or out of scope items are tremendously useful when project managers need to manage expectations. This is especially powerful if those stakeholders are involved in and accept the scope document at the start, but applies to anyone in the business attempting to introduce feature requests or direction changes that aren’t in scope.

Does the business broadly understand ‘why’ this project is needed?

Buy-in from the wider business on an IT project has many knock-on effects that might be hard to see from the very beginning. Consider things like getting people from across the business involved at key moments – such as permanent employees seconded from the BAU team in to help and provide invaluable experience. If there’s strong support for and understanding of the project and its value for the business, the project can often run much smoother.

But the scope benefits significantly from the same understanding level as the business challenge being actively worked on. The involvement of stakeholders and other critical roles in the business to develop the scope will be able to do so much better if they have the context around the why. This will be the job of senior leadership and a steering committee to engage and communicate with stakeholders effectively from the very start. Often in the case of a technology project, the challenges may well have been identified by the stakeholders in the first place. Buy-in to the project will be there already. How the solution is designed and delivered may be subject to debate and negotiation before the project gets underway and the scope is confirmed.

Need guidance on your IT project?

IQANZ provides specialist assurance services for technology projects across the private and public sectors. We apply proven assurance methodologies along with a high level of technical expertise to help guide projects and programmes to success. If you’re interested in getting independent, expert help on your technology project, get in touch with our team.

Where to next?

Read our other technical project resources:

Common IT Project Risks

Common IT Project Risks

Risks are present in every project, but technology has a degree of complexity that makes risk management even more crucial.
Learn More >>

Designing a portfolio delivery plan IQANZ

Resourcing A Development Team

IT projects require a number of skills to deliver. We explore the process of resourcing your development capability.
Learn More >>

Guide to portfolio governance IQANZ

Preparing An Organisation For New IT Systems

Digital transformation brings with it new platforms, software and systems. How can organisations prepare for this properly? We explore this in our guide.
Learn More >>

Building a balanced project portfolio IQANZ

Waterfall IT Project Management

Waterfall is one of the more popular project management methodologies in technology initiatives. We discuss why.
Learn More >>

Secret to successful portfolio delivery IQANZ

Scrum and Agile In IT Projects

Scrum has become the most popular Agile methodology for projects.
Learn More >>

Prioritising projects in an organisation IQANZ

Scoping An IT Project

IT projects are complex and need clearly defined parameters to be delivered within budget. Read more about scoping tech projects in our guide.
Learn More >>

Latest Technical Project Articles

What to Look for in a Quality Assurance Provider: 8 Key Attributes for Project Success

What to Look for in a Quality Assurance Provider: 8 Key Attributes for Project Success

Sep 23, 2024

When it comes to selecting a quality assurance provider for your project, the focus should not only be on technical expertise but also on the soft skills that truly make a difference. With years of experience in quality assurance, I’ve identified several key attributes that define an effective assurance provider, helping you navigate the complexities of your projects with confidence. Let’s explore the eight essential qualities your assurance provider should bring to the table.

read more