Requirements Management is important too!
I had reason to have another look at risks of system implementation. It’s an area of systems management benefits from taking an approach informed by the best principles of cyber-security. It seems I have written several articles that apply to this topic. Regular readers will know I am a fan of knowing what one’s doing and not making it up.
There are previous articles on strategy, vendor management and release management but this article, while reinforcing the need to perform these processes well, also examines the initiation, portfolio management and project management aspects of systems implementation.
Even if implementing a third party package, organisations need a systems development lifecycle methodology which defines the standards by which functional requirements, non-functional requirements, data governance policies, IT security policies and compliance policies are documented and authorised. Looking at this requirement in more detail, an organisation needs authority and entitlement models which take into account the principles of least privilege and segregation of duties. Non functional requirements include availability goals, performance goals and the capacity plan.
Any decision to buy build or assemble needs to be justified and supported by a cost benefit analysis.
If implementing a third party product it is necessary to create and maintain a requirement statement, requirements gap analysis, a cost benefit analysis, a risk analysis and a formal cost justification/business case.
The project plan must include test plans to ensure the systems product does what it claims to do, and meets the business requirements plan. It is best practise to perform performance and capacity tests on a shadow system i.e. not on the production system nor using production data.
It's also crucial that roles and responsibilities are defined and that there is a skills plan which is tracked and that training and accreditation is available to staff, and that there is a skills retention plan. I am of the view todat, that skills supply is a crucial issue in deciding what to buy or use.
All the plans require amendment policies to ensure that they remain relevant to the organisation’s business need and this market adoption policies. i.e. Organisations need flexibility and a plan to keep up with both market supply and external regulation changes.
In my last strategy article I discussed a portfolio management technique described to me by Dan Remenyi, and conclude,
.. business strategy should drive portfolio and project management choices. Portfolio management determine the allocation of development funding, priority, maintenance funding, project risk appetite, people skills, project governance and software sourcing policy and as result of choices made one can select the appropriate platform super architectures …
One thing I left out is that a key driver for the decision to build software should be that the organisation is looking for competitive advantage through a unique process. Those software products that are needed but not expected to deliver such competitive advantage can or should be bought. Since the organisational differentiator is the business process, the corollary is that if buying software one should adopt the optimum processes defined by the system author. The worst solution in terms of cost benefit is to buy a package and then seek to adopt it. The other item of care is that the proposed purchased product does what one requires i.e. the procurement process needs to test the proposed product against the requirements analysis. I also argue that compliance software which includes the accounting solution is best bought from a significant market player.
Some public or 3rd sector organisations find it hard to define their business strategy.
In my note on Vendor Management, I talk about the principles to be applied in building a risk based vendor management policy, how to determine which suppliers are important, which less so, and how to manage the service delivery and risks of dealing with vendors, including, legal and regulatory requirements e.g. adherence to GDPR and or other applicable legislation; reporting and reviews; non-disclosure; IPR/RTU; incident management; and other specific policies to comply with if important to the agreement; and obligations on subcontractors; screening on staff etc. and vendor market exit.
In my longer note on Release Management, I again call for written plans requiring an impact analysis including a data privacy impact analysis, testing records, including that the requirements have been met, the business case is still valid and that the proposed systems meet their non-functional requirements. It requires that all changes have a rollback plan. Also that any documentation including configuration records and any knowledge management artefacts are available. A training and communications plan is also required. The longer article, talks of emergency changes, and the controls placed on the change control process.
Finally appropriate roles and responsibilities need to be defined and implemented and an appropriate segregation of duties implemented, monitored and controlled.
Good people have thought about how to do this well; it would be best to stand on their shoulders!
The was originally posted on Linkedin and mirrored on Medium on 29 July 2023