Analyse this!

Analyse this!

• Daishik
• 13 Jun 2022
• 0  

In this article we’ll look at the second type of shortcut you can take on your projects to reduce headcount, time or cost.

Good analysis - produced ahead of development - is supposedly critical to ensure that the solution developed meets requirements and expectations, and identifies potential problems. Yet I frequently work with teams - sometimes spread over multiple geographic locations, attempting to understand, build and test complex software without any up-front analysis and zero ongoing analyst support.

It’s true that for simple projects the analyst role can be combined with other roles. Many teams rely on the project manager, tech lead or senior developers to perform the role of analyst. This is certainly workable, provided that adequate analysis time is provisioned. 

In my experience though, such arrangements do not scale up for even mildly complex solutions.  They also do not scale well for large teams or geographically distributed teams where several part-time analysts can complicate rather than simplify understanding.

I myself have occasionally worked as an 'analyst developer'.  What seems to happen in practice is that the work of ‘analyst’ is often forced in between the already full-time work of ‘developer’. 

An analyst developer is more likely to constrain her time on the analysis tasks and launch headlong into development. She’ll then adopt a system of ‘just-in-time analysis’ when confronted with an issue. She is also less likely to properly share or document the knowledge and the solution for future review and reuse.

To be honest, developers are generally not trained to be professional analysts. The risk is that they fail to ask the questions that should be asked because their view of the project is limited by their perspective of the business model, or coloured by their own technical knowledge, or biased to a particular technology or solution. 

Avoid analysis, avoid paralysis-by-analysis

Nevertheless as a unique business, you know what you want. And what you don't want is the overhead of a bunch of analysts telling you what you already know or what you think anyone can simply figure out.

You also don't want people to stop and think about what they should be doing, and why. After all they should be getting on with it, right?

Let me tell you about some former clients; names have been changed to protect the guilty.

StyleCo is an otherwise successful business that has factored in the negative 'cost' of skipping analysis and has a policy of never using professional analysts.

When a StyleCo developer is assigned a feature, she must work out from multiple sources, ad-hoc discussions, emails and presentations not only how she is supposed to produce, deliver and integrate the feature, but also the actual functional and non-functional requirements. She must do this analysis at the same time as she writes the code.

Quality and accuracy depend wholly on her ability to obtain the correct details from the appropriate people in the business and settle any contradictions and  misunderstandings amongst those sources. 

Stalled development is a fact of life at StyleCo. This can happen because a key individual isn't available to confirm a requirement or point of fact. Or for work to be done, then to be redone because a different stakeholder has a different opinion to the person the developer asked earlier.  Meanwhile another developer, working on a complementary module, talking to a different stakeholder, or asking slightly different questions, gets a different set of requirements and parameters.

At other times, solutions are simply incomplete because the developer didn’t ask adequate in-depth questions. These shortcomings might be discovered during testing if lucky - and at worst after delivery to the customer.

Next let's look at FinCom, a global multinational with a complex portfolio of products which require a very high level of mathematical competence to understand. It would be costly and time-consuming to get the right kind of analyst professional into such a role, so they just manage without one wherever possible.

FinCom passes the role of analyst on to their senior developers.  With such complex products and without the skills to analyse them, when a new feature is required, the simplest way to cut to the action is to find a similar feature from a different product suite, copy it, and attempt to customise it.

Only once the feature has been substantively developed and been through a round of  user-acceptance testing (UAT) does deeper knowledge or insight begin to emerge about the feature.  It is the UAT process that raises the queries, clarifications and the changes that ultimately hone the feature.

Additionally, FinCom don't waste their time with a comprehensive testing strategy. This means that functional testing, integration testing, system, stress, and user-acceptance testing frequently happen at the same time on the same environment. Without analysis and clear acceptance criteria, testing is generally ad-hoc and scatter-gun with some scenarios or edge-cases never exercised.

Notably, both FinCom and StyleCo are successful businesses, and despite the issues, manage to deliver their projects.  It is therefore certainly possible for you to do so too!

The inenvitable downsides

Before we move on, we do have to explore the consequences. The issues at FinCom and StyleCo may not be significant or immediate concerns for senior managers or their end clients but they do have a corrosive effect on the development teams, and in the long term, on the organisation.

 In software development, a professional analyst frees the development team from the task of finding, assembling and distilling information directly from the business or client, so they can focus on overcoming technical hurdles and delivering the actual product.

Analysis focuses attention and

• identifies key value-driving features
• helps to identify gaps in knowledge
• identifies contradicting expectations
• increases understanding and knowledge of the problems and solutions
• describes how various scenarios should be managed both within the software and in the broader business process
• defines success criteria for the solution
• clarifies the project boundary and limits scope creep
• helps triage defects and issues

Whilst shortcuts in analysis may be a cost saving, they could also mean the slower overall project delivery, reduced morale and emotional investment in the project/organisation, and increased stress and dissatisfaction amongst the team.  There could be increased tension between the team and the wider business.

Pressure on the team may increase because of rework consuming time allocated for other features, enhancements or fixes.  In some organisations this can lead to increased stress and longer work hours with a knock-on effect on retention and recruitment.

If you're able to weather these negatives however, this article demonstrates how you too can run successful, complex software projects without analysis.  

We'll explore additional strategies in a future post. Up next though, is the problem of quality control.

Click on the links below for the other articles in this series

• Tearing up the rulebook - We know our business is unique, so let's just tear up the rules and do everything in our own, unique way!
• There is no Plan A! - Cutting back on discussions, workshops and planning of work, or even skipping them entirely, is an important shortcut that could reap dividends!
• Testing times - Another favourite! Shortcuts on testing and quality assurance is a great choice if you're keen to cut back on cost, resource and time
• Getting away with it - So you've cut corners and played fast and loose with best practices. Here's how you can still succeed in spite of the consequences!
• The gods among us - The ultimate, and most effective solution to managing the fallout from shortcuts. But there is a price to pay!