Hi there,
I am a Business Analyst mainly working on Software projects. With each project I get pieces of Software delivered which is not aligned with the Specifications that were signed off. There are several reasons for this.
1. Developers making decisions during development that a solution if implemented which is slightly of the spec, but still meets business requirements but not functional.
2. During development, the business change their mind when they see a working prototype of the software. Asking for changes as they walkthrough the process.
3. During UAT the changes been asked for because of features that were not being thought of during requirement Phase.
Because of pressure, the developers are working at fast pace to deliver on time. That would mean that as changes are requested, they are implemented and thus requirements specs are updated after the implementation. There are some change control measures in place, but just looks at major changes. i.e. Scope changes or when a developer flags up that the change to the software will be a big job and impact timelines for delivery.
My question is should there be tighter change control procedures to handle any change big or small ? This could have impact on delivery timescales even on small changes.... There will always be the issue of the specification that will be out of sync with what is implemented.
Any suggestions ?
Many thanks,
Carl O.
Hi Carl,
Think there is another question here. Are you as the business analyst involved in the construction from a functional testing viewpoint? Big danger from what you've described is that the delivered system doesn't meet the original idea of the project or that the changes work in silos but the overall functionality doesn't work. This is SUCH a common problem. Developers decide to do something slightly differently, usually because its easier but also often because they misinterpret the specs and the change doesn't work within the overall requirements. You should also be involved if the users make changes. You are the one with the overall functional knowledge, so they are quite capable of doing the wrong thing, albeit for the right reasons.
Sounds like you need to be involved more closely in the construction phase. That should ensure that you here about changes and get to agree to them and that you catch any changes the developers make early.
Do you run workshops with the developers before they start work? If not, you should.
Projects should always have a change control process. It doesn't have to be complicated and time consuming but you need to be on top of what's happening.
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using: