5 Reasons To Avoid Analysis in Advance

Hi, I'm Neil Benson from Customery and your host for another episode of the Amazing Applications show. 

Welcome back to our regular listeners. I appreciate you following the podcast, sending in your questions and comments and sharing the show. 

If you're new to Amazing Applications, welcome. We're here to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks and create amazing agile Microsoft Dynamics 365 and Power Platform applications that everyone will love. 

I hope you find every episode useful, inspiring, educational or thought- provoking. 

If you do, you're welcome to follow the podcast in your favorite podcast player so you don't miss future episodes. 

You'll find show notes and a transcript for this episode at https://AmazingApps.Show/97. I'm launching a new website for the Amazing Apps show and renumbering all the episodes by combining the episodes and the old Scrum Dynamics podcast with the renumbered episodes from this show. Visit AmazingApps.Show, and the first person to subscribe to the show's mailing list will get a free t-shirt from the show's Swag page. 

In this episode, I'm going to be sharing five reasons why I think you should avoid analysis in advance when you're building Dynamics 365 and Power Platform applications. 

I've been there. I was a business analyst for 10 years, trying to write the perfect requirements specification. But recently, one of my Scrum from Microsoft Business Apps students, Tommy Boisvert, a CRM business analyst from Montreal in Canada, challenged me because he thinks it's easier to design amazing applications once you know all the requirements.

And while I think that assertion sounds plausible because I chased it for 10 years, I no longer believe it's possible or the best approach. So this one's for you, Tommy.

Five reasons to avoid analysis in advance when building business applications. 

#1. The point of peak ignorance. 

I'm working on a new project and we've got a subject matter expert who's a team leader for primary team that's going to be using our Dynamics 365 customer Service application. She is the key subject matter expert for us describing how they do things today, the team's pain points and the capabilities that would be useful in solving those challenges.

She has seen Dynamics 365 once. How on earth can we expect our subject matter expert to be able to imagine what to call every table and column, how to layout every form and view, and what data she'd like to see in every chart and dashboard.

This team has been working on a massive, shared spreadsheet for the last six years. Our subject matter expert has never worked with an enterprise business application like Dynamics 365 before. She hasn't had any training in entity relationship diagrams, in UML, or business process modeling notation. So documenting everything in a requirement specification, isn't going to elicit any meaningful feedback from our key subject matter expert.

Luckily in this project, we have a business analyst with Dynamics 365 experience who has been working in the organization for nearly a year before this project started. So he's got a good understanding of the organization's strategy and objectives, its structure and its leadership, its jargon and their existing systems, policies, procedures, and their culture.

Most projects are not this fortunate. They don't have a business analyst like ours. If you're a business analyst or an architect from a Microsoft partner, you'll usually have a brief handover from the pre-sales team before you start working on the requirements, analysis and design. You've got almost no understanding of how the organization works when you start the project. 

If we want to analyze all the requirements in advance, then we're going to do it at the point of peak ignorance. These few months at the start of the project is when our key stakeholders know the least they'll ever know about Dynamics 365 or Power Apps or Power BI. If we attempt to complete all the requirements analysis and advance in an analysis phase, and then all the solution design upfront in a design phase, it's when our business analyst and our solution architect know least about the organization.

Imagine if there was an approach to building business applications that allowed us to defer requirements analysis, and solution design, for a feature until just before we started developing it. If we could use an approach like that, then with each feature we develop, our stakeholders would know more about Dynamics 365, Power Apps or Power BI than they did last time, because they've just seen it, they've tested it. Maybe they've even used it in production. 

If we could use an approach that deferred requirements analysis and solution design, then our business analyst, solution architect, developers, and testers would know more about the organization than they did last time because they got previous experience building and releasing features for them. They've got feedback. They've got experience. Maybe they've even got some scars to prove it or tattoos in the case of some of my Dynamics 365 friends.

#2. Lack of prioritization. 

Like I said earlier, I spent 10 years as a business analyst trying to write the perfect requirements specification, but I have to admit, I haven't written a requirement specification for a long, long time now. 

These days, most of the business requirements specifications I've reviewed are published as part of a public sector procurement exercise to select a Microsoft partner.

Within the request for proposal pack, there will be a requirement specification. Sometimes it's a Word document with heaps of detailed business requirements written as use cases or user stories; often badly written, but that's a topic for another episode.

Sometimes the requirements are specified in an Excel spreadsheet, which has a major drawback of being a sucky application for writing anything, but at least we can sort and filter on the columns of data about the requirements. Usually, one of those columns is priority. Either high, medium, or low, or sometimes must have, should have, could have. 

I've seen requirement spreadsheets with 200, 500 even 800 requirements in them. And I bet some of you listening are laughing, cause you've seen lists with 10 times that number. 

You might even have written them, but you know, there's no here on the Amazing Apps show. How could you!? What were you thinking!? 

If we had a list of 300 requirements, I bet you 200 of them are in the highest priority category.

And if you're a development team about to start building 200 high priority features, where do you start? Do you sort the requirements alphabetically by title or stakeholder? Uh, I have no idea!

Instead of sorting our requirements into priority categories and asking the developers to guess which requirement within the highest category is the most important, imagine if we could use an approach that orders the requirements by importance using stack ranking with the most important, impactful, valuable, or necessary at the top. If we could use an approach like that, then it would be clear to everyone where to start, and which features are going to have the most impact. 

If we're going to use an approach like that then we could focus our analysis and design effort on those requirements at the top of the stack. And spend hardly any time on requirements near the bottom of the stack. This would be awesome because there's a good chance that those low value requirements will never see the light of day. And we wouldn't have wasted any effort specifying them in detail before categorizing them as a low priority requirement.

The third reason to avoid upfront analysis is that it leads to over-engineering. On another project I'm working on with a Microsoft customer who has just finished deploying Dynamics 365 Customer Service into their organization, which has got about a hundred users supporting employers and workers in their region.

The launch, to be honest, hasn't gone well and feedback from the users is that the new system is extremely complicated and hard to use. Call handling times have shot up and call waiting times are over an hour. Customers are frustrated and complaints are rising as quickly as the call handling times. The general manager is under pressure internally and externally. 

Looking at the system design, I can see several areas where it's been over-engineered. They've used the account and contact tables for employers and employees, but they've also got custom tables for organizations and workers. Strange. Apparently, this is to handle a few exceptional scenarios where an organization has businesses in several industries or a person has several jobs in different industries.

These 1-in-1000 long-tail exceptions have been allowed to wag the dog of the design. The system has been overly complex for 999 use cases to handle those one in 1000 scenarios. 

The standard notes feature has been replaced with something custom that takes eight clicks and has the unfortunate side effect of being able to be easily linked to the wrong record.

There's a custom form record that can be converted into a case because in the old way of working every business process started with a customer filling in a form, a paper form, which would be scanned and sent to the case management team and converted into a case. They've translated that paper-based design into the Microsoft Dynamics 365 solution design. 

The Microsoft customer is in a terrible situation, and unfortunately they're not unique. 

The business analyst and solution architect who analyzed the requirements and designed the system probably had Microsoft certifications and knew Dynamics, 365 Customer Service well. During the testing phase, the application probably passed all of its tests scenarios and was approved for production release because it met all the requirements. But the system was fatally over-engineered, I believe, because of all that analysis in advance. 

None of the requirements spraying from experience with Dynamics 365 Customer Service. They sprang from workarounds and frustrations that the stakeholders had with the system Dynamics 365 replaced; which was a complex, custom developed ten-year old legacy system. Now they've replaced it with a complex, over-engineered new, legacy Dynamics 365 application.

Imagine instead of analyzing all the requirements in advance and designing complex features upfront, if there was an approach where we could have identified a few features that were going to have the most impact and build those and release them to a pilot group of users. Those users could have given us their feedback and shown us exactly where our application wasn't quite able to support common business processes or where usability needed to be enhanced.

There are a couple of critical questions that are much harder to answer when an application is still on paper compared to when it's in production. For example,

What was this feature like to use and what could we do as a development team to improve it? or,

How often does this scenario happen in a day, week, month, or even a year? 

If you can't answer questions like that because you're doing all your analysis in advance, then you run the very real risk of building features that are complicated and hard to use because they meet an obscure scenario that only happens one in a thousand times. 

#4. The illusion of completeness and the reality of wasted analysis. 

Sometimes we think that the optimal design can only be achieved when all the requirements are known in advance. I think that's a pipe dream because it's impossible to know all the requirements in advance. 

You might think you've nailed it. You might've written one of the world's greatest requirements specifications in the history of Microsoft business applications. It's complete and unambiguous. It's detailed and technical enough for the architects and developers, but not too detailed or technical for the stakeholders to read it and understand it. 

It's even more perfect than the shopping list my wife sends me to the store with. Peas? What does she mean, peas? Frozen peas? Tinned peas? Mushy peas? Oh, she meant sugar-snap peas from the pod. Well, why didn't she say so? She only tells me that when I got home, of course. 

But then something's going to happen to upset your perfect requirement specification. It could be: a change in leadership or strategy; a corporate acquisition or divestment; or a reorganization of some departments; or an announcement from a competitor, or a regulator, or a government agency; or it could even be at an announcement by Microsoft in a release plan for an upcoming wave, or from an ISV; or something just as commonplace and mundane as a simple change of mind by your project sponsor. 

Whatever it is, has upset your perfect requirement specification and sent you scurrying back to make changes to the delicate balance of your Word document and it's accompanying spreadsheets. 

It takes weeks to draft the changes and get the specifications approved by your stakeholders. Then you have to hold workshops with the architects and get the new designs specified and estimated so the change request can be submitted to the project steering committee for approval.

Even if your change request is just to get an approval to drop a previously agreed requirement, your change request might not take as much effort as introducing a completely new requirement, but it means that all that work you did before to analyze that requirement, to specify it, to document it and design it, all that work was wasted.

What if wasted work was avoidable? 

Imagine there was an approach to building business applications that wasn't founded it on the illusion that requirements needed to be analyzed in advance. 

Instead, we proceeded with coarse-grained requirements. Designs and estimates that are documented as lightly as possible, just enough description so that we can reach a mutual understanding about them, roughly estimate, then order them. This approach embraces change and enables us to respond successfully to events that are outside of our control because our requirements are simple fragments and sketches rather than specifications carved into stone tablets.

 The last reason I think you should avoid analysis in advance is the opportunity cost. 

The chances are that your organization is anticipating a positive return on your investment from your application, right? If they're not, perhaps you should stop now and find something more fun to do with the rest of your career.

Given that you're Power Apps or Dynamics 365 application or your Power BI analytics will generate benefits once you're in production, then there is an opportunity cost of every week that goes by that you're not in production yet. 

Imagine these two scenarios. 

The first one is a 12 month project that spends four months in analysis and design, five months in development, and three months in testing and deployment. The project has gone well. You have delivered the expected features on time and on budget and you're in production after 12 months. Woohoo!

The business change is well managed and your organization starts accruing benefits three months after the release and the project is successfully closed. 12 months later on your project has reached its break even point so that the accrued costs are now matched by the benefits you've achieved. From month 16 onwards, your project starts delivering a positive return on your organization's investment.

Imagine another project that takes a different approach. 

Instead of releasing all the features after 12 months, they build a couple of features and release them after just three months. They are the most valuable features in the entire application, and their impact is felt quickly. The project is still building additional features, but the benefits have already started to accrue. Development continues for another nine months. The business change has already been completed by the time the last few features are deployed. The break even point is achieved three months after the release. And from this point, the project starts delivering a positive return on investment. 

Now, I appreciate this is a fictional scenario, but I hope you can appreciate the point I'm trying to make here: when your application is still on paper, in the analysis and design phase, it's not in production. Our organization only starts to accrue benefits when your features are being successfully used in production. The longer you stay on paper, the more it's costing you. 

Of course, the longer you stay on paper in analysis and design, chasing the illusion of completeness, then the great other chance of an external event forcing you to change your design before you've launched a single feature or experience a single benefit.

 So there are my five good reasons to avoid analysis in advance: 

1. Peak ignorance. You're analyzing the requirements during the period when your stakeholders know least about Microsoft business applications and your analysts know least about their needs. 2. Priority categorization. Your requirement specification doesn't order the requirements by business value. 

3. Over engineering. Your requirements are likely to lead to over-engineered complexity and a rejected user experience.

4. Wasted effort. You're spending time chasing the illusion of completeness and putting yourself at risk of a significant change that will derail your requirements specification. 

5. Opportunity cost. By deferring deployment you're deferring the benefits, and costing your organization money.

I'd love to hear your feedback about analysis in advance, especially if you're a big fan of that approach and you disagree with everything I've just said. Perhaps you'd like to join me on a future episode and deliver five benefits of analysis in advance that agile teams are missing out on. 

You can email me at amazingapps@customery.com or leave a comment on this show's post on the Amazing App Show LinkedIn page or the Amazing App Show on Twitter.

Bring it on.

Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode available. 

There are also shortcuts so you can follow the show on all major podcast players and you can follow Amazing Apps Show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.

You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.

 Visit https://Amazing.Apps.Show. 

Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!