Accurately Scoping Projects

By Paul Darby – Delivery Lead, Roq

The intriguing, and all-too-often, frustrating world of IT projects and programmes is continually evolving, but the overarching demands from individuals and organisations alike are for the most part constant: 

• Deliver all the scope,

• Deliver on time,

• Deliver to budget,

• Deliver great quality,

• And wow your audience if possible. 

It’s interesting that although these constants exist, the world in which we live is always adjusting – and at serious pace.  Whether it is technological advances, the position within the world of competitive advantage, or both, the increases in choices that people and organisations have, and the ease by which they can make those choices have increased the urgency and the pace at which IT projects are required to be delivered.   They’ve also increased the reactive nature of individuals and organisations during the project or programme.  It would be fantastic to assume that all of the technological advances and improved methodologies in turn have improved the ability for IT projects to meet those constants – it is sad to reflect that this is all too often not the case.

So, why do businesses run into problems?

It's impossible to tie down to a single reason why organisations so often run into problems.  As alluded too, there is very often a tendency to try to move very fast, but a fast pace is not always a root cause of problems – yes, it threatens to burn out staff if maintained, and it can increase human error; but if all of the mechanisms are in place to support it and the teams involved have clarity of what is expected, then high pace can be achieved – albeit for short periods. 

And that brings us to what is, in my opinion, one of the major causes of project and programme challenges – unclear scope!

Tackling the accuracy of scope

Within this article ‘Scope’ is defined as two levels of consideration.

1. Scope clarity

The first and most obvious consideration level that aligns with the constants mentioned above is the unclear scope relating to the solution being produced. 

Unclear scope is caused through many different omissions of which the following are typical:

• Functional and non-functional requirements are not captured,

• Business requirements are not captured,

• The end user hasn’t been engaged to input to the requirements,

• Conditions of satisfaction haven’t been captured,

• Operational use of systems hasn’t been considered,

• Interactions between systems has not been thoroughly considered,

• Appropriateness of the technology has not been considered in conjunction with all of the above,

• Supplier expectations and the time and complexity to realise and then prove the delivery of these considerations haven’t been investigated. 

This isn’t an exhaustive list, but any one of these presents a real problem for the realisation of effective Quality Engineering across a project or programme and will very likely present extended timelines and increased costs.

2. Scope enablers

The second scope level which has a direct impact on the ability to deliver the solution scope (well captured or not) may be considered as ‘Scope Enablers’ within the project or programme delivery. 

Imagine a scenario, where all of the points above have been addressed perfectly, but the requirements captured are not housed in a central location and have no configuration management and associated communication channels to relay change.  Essentially, great requirements were captured but they are not controlled, which in turn creates a situation where unclear solution scope can exist or can gradually manifest over time. 

To take this a step further, the tools have not been correctly identified or set up to facilitate appropriate measurement of development completeness, or the success of the testing and the defects cannot be tied back to the requirements, so there is no easy way of seeing what has been developed, and what works.

The risks of unclear scope, both at target solution and scope enabler levels should be on every organisation’s risk list from day one and should be a primary focus. 

Not addressing these risks early will very likely cause a breach of time, cost or quality tolerances and may ultimately impact an organisation’s reputation and value.  Understanding what is wanted versus what is needed across the resultant solution and the approach to delivery is vital.

The Roq team see and help organisations deal with the resultant challenges presented by unclear scope across both levels all the time.  We are very good at this!  But, the ideal would be to avoid the challenges presented by unclear scope from the start.  Ultimately, this is Roq’s mission with any client engagement.  Introduce Quality Engineering at a point that helps organisations achieve those constants - deliver all the scope, deliver on time, deliver to budget, deliver great quality and wow your audience if possible. 

The concept of ‘Shift-Left’ - which means that the de-risking of a project or programme and the resultant solution starts as early as possible - is a key Quality Engineering mantra that we deliver to all of our clients.

So how do we do that?  

Roq delivers critical key services aligned to our principles that have a direct impact on the realisation of solution scope and the enabler choices required to be made to successfully deliver. 

Early engagement with Roq means that the quality of requirements can be reviewed, the mechanisms for maintaining and flowing the information to the delivery teams can be shaped into mechanisms that truly work and deliver value appropriate to any cost incurred.

This helps organisations get the scope question in check and keep it that way.  Ultimately an organisation has to decide what the solution scope is, but Roq can help this journey by reviewing the quality of requirements and working closely with the business to derive the correct understanding of required functionality and business process which in turn will present a developable, testable and measurable solution.

Additionally, enabling Roq to engage early will ensure that processes can be defined in a way that gives clarity to the scope of processes and procedures that enable successful delivery.

For example:

• Third-party engagement expectations can be set and collaborative testing efforts with user groups can be correctly defined, managed and delivered. 

• Supporting activities can all be shaped early on, thus defining the delivery approach ‘enabler’ scope, covering:

  • tool choices and setup,

  • managing deployments to environments,

  • defect management,

  • automation approach and framework production,

  • transition to live planning,

  • ongoing test readiness,

  • change management,

  • and measuring acceptance and readiness.

In this article, I’ve aimed to cast light on ‘accurately scoping projects’ in two ways:

1. The scope of the resultant solution within clear constants that often undermine the successful delivery of the solution

2. The scope of the ‘enablers’: tools, processes, procedures, engagements, management etc. that enables the resultant solution scope to be delivered, proven and maintained ongoing. 

In summary, both need to be considered correctly and approached effectively to offer guarantees of effective project or programme delivery and both should be addressed as early as possible.

Methodologies such as Agile, Iterative, extreme programming etc. are not get-out clauses for carrying out this up-front thinking.  Yes, they change the overall approach, but the solution scope still needs to be right and the mechanisms for delivery and de-risking the solution still need to be right.

This is what we at Roq do, and if you’d like to reach out and talk more on this, or find out how this approach could help your business, we’d welcome the opportunity.

Get in touch at ask@roq.co.uk.