The analysis phase: time to grow up?

When small software companies get bigger they embark on what can be a bumpy ride of change. One of those changes will probably be to do with the way they tackle the analysis phase of the software development life-cycle (SDL). Just to be clear, when I say “analysis phase”, I mean the part before coding starts i.e. requirements elicitation, analysis and system specification.

Typically (although I am sure that there are plenty of shining examples where this is not the case) small software companies with a handful of developers, where the entire SDL for a project is covered by one or two developers, tend not to have a formalised analysis phase. Why is that?

Developers like to code. Coding is the fun bit. Coding produces something tangible and allows you to show-off. Coding is being productive and is satisfying. For most developers doing anything other than coding is a chore, something that should be avoided where possible or at least kept to a bear minimum.

So when the entire SDL is being covered by one developer he/she will find ways to spend more of their time coding and less on the chores. The temptation of course is to dive straight in and start coding instead of spending time planning, eliciting and validating requirements, analysing the business, specifying and validating the solution and documenting all of the aforementioned activities. Of course we all know what happens when the chores don’t get done. The risk that the project will fail increases astronomically, better put: the chances of the project being a success are slim or non-existent.

If this scenario is true to life how then do small software companies survive?

The answer may be in the question. The company is ‘small’, the employees are passionate, dedicated and committed. The chores, like requirements analysis and system specification, tend to be done on the fly and in memory (in the developers heads or at best scribbled on the back of a bus ticket) and documented retrospectively. This works (for the most part) because these tasks are being performed by the same person that is doing the coding. However this, ‘make it up as you go along’ (MIUAYGA) approach, makes budget control and scheduling a nightmare and leads to quality problems. The inevitable over-runs, architectural conflicts, solution mismatch (the product doesn’t satisfy the requirements) etc. are absorbed by the passion, dedication and commitment of the employees working nights and weekends.

However unrealistic this MIUAYGA approach might be in the long run (unless the rewards are so enticing that the employees are willing to forego any semblance of a ‘life outside work’), it does work in the short term. This is often how small companies and start-ups get going and build up their client/project portfolio. But what happens when these companies start to grow? At some point they will reach a critical point where the number of employees and the number and or complexity of the projects, makes the MIUAYGA approach unworkable. Either that or those passionate, dedicated and committed employees will start to burn-out and no amount of carrot dangling will be enough to entice them.

Perhaps ‘unworkable’ is the wrong word. Failing to abandon the MIUAYGA approach, when it becomes unworkable, could well lead to something akin to flushing the company down the toilet.

Aside from the burn-out factor, the problem is this. As the projects get more complex and require more man-days of work, it becomes impossible for one or two developers to manage the entire project. Where once one or two people were fulfilling the roles of Project Manager / Leader, Business Analyst / Requirements Engineer, Technical Architect, Developer and Tester, these roles now have to be delegated to other people. So now you have a team of people working on the project, each in their own discipline. Lets go a step futher. The company continues to grow, the projects get more complex, costs become scary. To keep things under control oversight roles are created to make sure that everyone is following the companies strategy, the best solutions are being chosen, skills are being deployed in the most efficient way and high quality products are being delivered.

With so many people directly involved in the project and several others with a vested interest, the MIUAYGA approach would soon lead to anarchy, failed projects and bankruptcy. Accurate and up-to-date information needs to be shared, schedules need to be produced and monitored, test plans need to be created, requirements need to be catalogued and tracked, the business processes and rules need to be modelled. All of this information needs to be formalised, standardised and documented in some way so that not only can the project team communicate with each other and the other project stakeholders, but also because these artefacts are project deliverables in their own right.

This means that the once haphazard just-in-time (often just-too-late or not-at-all) undocumented analysis phase is not going to work. It needs to be replaced and preferably with industry standard and well proven methodologies.

So how do you go about adopting a more formalised and stardardised analysis phase in a company which until now has been practising the MIUAYGA approach?

That will be the topic of my next post.

Published by

James Kerr

Business Analyst