part0032

New Build:

The introduction of new applications or new technology products into the organisation. Ensuring that non-functional requirements have been factored into the solution, appropriate testing has been conducted, and operational readiness has been confirmed.

This chapter will help you:

• make the case for engaging technical and operational teams early in any new development

• factor in non-functional requirements to every new development

• include non-functional guidelines when selecting third-party applications

When a project kicks off to build a new application the initial focus of attention is, understandably, on gathering requirements from the business area who have requested it. Business analysts and software developers will hold conversations with the prospective users and map everything out. Your organisation might prefer to go the ‘quick’ route and seek out an existing package solution, rather than aim to develop it all in-house.

This may not pose a problem in smaller, tight-knit IT departments simply because the team works so closely together. The technical infrastructure person sits on the next bank of desks to the lead developer and they’re in regular dialogue.

That doesn’t always happen in larger IT departments where staff can be spread across separate ﬂoors, ofﬁces, cities, or even countries. Increased department size brings tipping points where teams become more siloed and insular.

The danger is that the fundamental issues raised above may not surface until much later in the project. The development team underestimates what work might be needed on the infrastructure front and run with the project for a long time before engaging the operations and technical specialists. This puts the technical team up against a very tight clock to design the necessary infrastructure and make sure it is ﬁt for purpose.

This can be more acute when a package solution is chosen because it is assumed that the vendor has worked out all the operational issues and everything will be speciﬁed down to the smallest detail. This is often a very false assumption.

Run a technical design workshop early in the project. Don’t put it off. Bring the necessary technical design authorities and operations specialists into the discussions sooner rather than later. It is better to surface those issues at the start of the project and maximise the time available for solving them.

1. Establish the technical engineering design for the system as soon as possible, steering everyone towards the use of standard infrastructure software and hardware.

Clearly, everyone wants to exploit new technology over time. Just remember that introducing new platforms and products increases the risk to the delivery schedule because their implementation is not tried and tested. Furthermore, having a wider and wider range of infrastructure software levels across your IT estate presents a maintenance and security headache. Having a clear technical architecture and IT strategic plan helps manage this situation

I have seen lots of project managers from software development backgrounds ﬂounder when tasked with the responsibility of coordinating infrastructure work. They have experience of requirements gathering, business analysis, coding and testing but they cannot get their heads around what needs to be done to link servers, storage, networks, and databases together and make them all secure and operable.

I accept this can be complicated. It can also involve a lot of coordination effort in larger IT organisations where each of these jigsaw pieces is handled by a different and highly specialised team of technicians. But avoiding it won’t help your project.

Recognise this technical work as a sub-project and make sure you have a project manager with sufﬁcient understanding to know the order in which the infrastructure tasks need doing and where the dependencies arise.

If necessary, I recommend you put an experienced infrastructure project manager in place to run this work as a sub-project reporting into the overall project manager.

As mentioned above, the business area will deﬁne what business process functionality they want in the new application and when they want the system to be available for use. However, there are other needs that must be factored into the design – those related to its day-to-day operational health and hygiene. The non-functional requirements, or NFRs.

Getting these integrated into the design and development process early is essential – no matter which development method you care to use.

If you don’t have a reference list of NFR’s, I recommend you get one drawn up. It should cover the management process areas identiﬁed in the IT Capability Framework in chapter iii. As the new application transitions to live operation the NFRs will ensure the following aspects will not be forgotten:

This approach can be used as a quality gate as the new system draws towards its launch date. Any NFRs that have not been ticked off the checklist represent a risk and should be clearly highlighted when the implementation is submitted for scheduling.

Selected items in the NFR list will require speciﬁc acceptance testing by the IT operational and technical teams. All too often I have seen contingency time eaten up in project plans to the point where this testing is severely compromised. And within the testing it is very easy for operational acceptance testing (OAT) to either get confused with some aspect of functional testing, wedged into the last few days of the project plan, or totally forgotten about.

OAT might involve testing the resilience failover of the underlying infrastructure, or a full IT disaster recovery test. It might be a dry run of the automated job schedules or the database housekeeping. It could be training such that the operators and technicians can conﬁrm they are happy to begin supporting the new system’s infrastructure.

The service is about to go live. Your help desk team have been given some training and familiarisation, but they’re still feeling a little bit nervous about how many incident calls they’re going to receive during the ﬁrst couple of weeks after it has been made available.

Having the development team disappear off onto the next shiny project will not be particularly helpful. Having a fortnight’s warranty period where the development team remain available on high alert will be a far better arrangement.

The decision to purchase a ready-made application from a third-party software vendor does not remove the need for NFRs. In fact, I would argue that the need is greater because you have no idea what operational standards and rigour the vendor has applied to their software.

Deﬁning a checklist of operational requirements and having these added into the invitation to tender documentation is strongly recommended.

As well as covering technical design requirements and the list of NFRs you would apply to internally developed systems, a signiﬁcant item to question the third-party software vendor about is their approach to maintaining compatibility with the underlying operating system and infrastructure software.

Specialist technology systems are used to operate and manage complex equipment in the health sector. In some cases, these control programs have been in place for many years and the suppliers have not felt the need to upgrade them to maintain compatibility with newer versions of operating systems like Microsoft’s

Windows. This has resulted in a lot of expensive medical equipment being hooked up to old pieces of hardware running out of date versions of Windows.

This security vulnerability was exposed by the WannaCry Ransomware attack that hit many National Health Service trusts across the UK in May 2017.

As well as the heightened security risk, the third-party vendor might prevent you from maintaining your infrastructure software at supported levels because their package application has not been tested and certiﬁed on these most recent versions or releases. You can ﬁnd yourself in a catch-22 situation:

You can guard yourself against this by exploring the application vendor’s commitments to maintenance before you agree to implement their package solution.