Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  Amount of Time For As-Is Modeling?
Previous Previous
 
Next Next
New Post 9/15/2008 8:02 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Amount of Time For As-Is Modeling? 

Craig,

Thanks for the compliment?

My view is that Agile is better than analysis up front when you don't want to do analysis up front. This is not meant to be a joke: my understanding of Agile is that it is lots of small changes that sum up to one big change. The advantage? Any cock-ups on the way can be fixed in the next release. The premise then is use Agile as you will get it wrong but with Agile you can fix it next release. The important thing for me here is that premise: you will get it wrong.

Where do most faults come from? Analysis (according to Standish Group Chaos reports). Which cost most to fix? Analysis errors because they incur the most rework as they are the first stages of the project. What do projects spend least time on? Analysis.

Summary: Project expend least time on the area where most errors occur and that cost most to fix.

Responses:

Agile: we might as well accept that then and make the impact of those errors as small as possible with lots of little releases.

(some kind - any kind really - of) Structured Analysis: we better make sure we get the analysis right.

There are pros and cons to each. No-one denies (as far as I know) that in the long run take 2 successful projects and the one done in Agile is more expensive (minimised economies of scale as compared to step change projects).

So, Agile is good for those who don't want to do analysis up front.

How can you change something when you haven't defined what you are changing (i.e. done the as-is) and what you are going to change it to (i.e. defined the to-be) and thus defined the change. Answer: trial and error, lots of little changes. You zig-zag to the final destination.

That's not say that loading the analysis up front doesn't have issues (analysis paralysis anyone?).

Bottom line: somehow, you have to do the analysis in a rigourous way - and I don't care what method or approach is used so long as the analysis follows a chain of reasoning that can justify every component of the change. Otherwise it is guessing and sometimes you get lucky but most times you don't and thems the odds.

Guy

 
New Post 9/17/2008 4:18 AM
User is offline saurabh
3 posts
No Ranking


Re: Amount of Time For As-Is Modeling? 

"So, Agile is good for those who don't want to do analysis up front."

 

I am not very sure if i can agree to this anyway. The whole conversation which has been happening here i have been following and can gauge the theme of it but such remarks are not what the agile model is intended for. yes true, 4% of the time goes into the analysis part but the fact is, agile is actually deployed in situation where practically the requirements can be changing every day and every week and you do not potentially want to wait for a half yearly release or a yearly release to seek results. now this may have lot of cases:

1, you may have some business requirements, which were quite complex in nature and a wrong step towards them could bring down the whole project. so why wait for a full release cycle of a year, and instead break requirements into smaller chunks and using agile deploy them so that you dont loose time and know exactly where you are heading into.

 regards

 saurabh

 
New Post 9/17/2008 5:12 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Amount of Time For As-Is Modeling? 

Hi Saurabh,

Thanks for your comments which I would like to respond to as Agile is a popular approach right now.

Your comment that Agile is useful when you don't want to wait for half a year or a year could be seen to imply that doing analysis will take that long. Of course, that may or may not be the case: doing analysis takes as long as it takes to do the job properly, just like Agile does. Certainly doing analysis does not invariably result in such a delay.

Your comment that “agile is actually deployed in situation where practically the requirements can be changing every day and every week” makes me wonder how long any solution developed will last – whether or not it is developed using Agile. If the requirements are changing so rapidly so is the required solution…and as an analyst I wonder why the requirements change so rapidly: is it because the real requirements really are that volatile (in which case developing any solution seems too short lived to be useful - have payback - unless you develop a solution that has as requirements the ability to change rapidly in response to changing business circumstances – careful thinking needed here to avoid huge costs!) or because the requirements are not really fit for purpose and as the thinking develops amongst the generators of the requirements, so do the requirements change.

Your comment that "you may have some business requirements, which were quite complex in nature and a wrong step towards them could bring down the whole project. so why wait for a full release cycle of a year, and instead break requirements into smaller chunks and using agile deploy them so that you dont loose time and know exactly where you are heading into." was intriguing: here I think you are suggesting that there are critical complex business requirements that the business can't wait for so you break them in to smaller chunks - but how can that be done without doing the analysis first? And if there isn’t the as-is part of that analysis, Agile or not, how can it be known know what is being changed? And if there is no to-be part of that analysis, how can it be known what it is being changed to? And if it is not known what is being changed or what to, how can it be broken down in any meaningful way?

In practice, a small change CAN be made and anything that goes wrong as a result is likely to be a small fix. This is the trial and error approach I have written about – and while it is not the most direct or cheapest way to make change, it is the least risky (in the short term but not long term) because it is a set of small changes. It's not the least risky in the long term because of the risk that not knowing what the start or end states should be  leads to the risk that after 100 changes it will be necessary to go back to the first and correct something that didn't come out as an error until the 100th change - because the end to end analysis hadn't been done – and now changes 2 to 99 have to be redone to cater for the new change.

And this may be where Agile will – in the longer term – have to be modified or abandoned. These longer term risks will materialize but they take time to build up and then – I suspect – like so many other approaches (RAD, JAD, Lean, Extreme anyone?) it will go out of fashion to be replaced by another approach offering the holy grail of making changes without the effort of doing the analysis of requirements.

Guy

 
New Post 9/17/2008 6:35 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Amount of Time For As-Is Modeling? 

Saurabh:

You stated:  "agile is actually deployed in situations where the requirements can be changing every day......"

The essential requirements on a software project are very stable:  The fundamental nature of a business is very slow to change.   If business requirements seem to be changing rapidly, it most likey  because they  were never correctly understood in the first place, or the scope was never nailed down.   Both of these problems result from in up-front sufficient analysis.

Project management can't wait to see results?   To quote Einstien:  Never confuse motion with action.   I have more than once walked into an agile or agile-like project where everyone was running 90 miles an hour and had to create data flow diagrams because a year and a half into the project no one knew what the scope was or how critical functionality interrelated.  

Doing up frount analysis is meant to increase produtivity.   The fact that it is so often done very wrong does not change this.

Tony

 
New Post 9/17/2008 6:36 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Amount of Time For As-Is Modeling? 

Guy,

I have some comments and a question for you. 

1. An Agile development approach probably has the same amount of analysis over the life of the project.  It's just done iteratively, like the development.  As a result there is the opportunity to correct mistakes with less cost (and you know the cost of quality over time story.)

2. Agile uses working software as one way of validating requirements, which these days can be done relativiely quickly (especially with scrum) and with good effect in relation to documents.  You yourself would have experience with prototypes - it's a variation on this theme. 

3. Project resourcing and burn rates mean that often a project team is established before the scope and requirements afre fully fleshed out - so rightly or wrongly, it's better to have the dev team working than sitting around reading incomplete docs

4. Analysis up front without the dev team in place and woking means that you are not in a rush to market, which is true say in some government areas, but in most product and service industries is not the case.  Note the agile maxim of extract value early.

5. Requirements churn does hapen on lengthy project becasue in most cases the environment is changeing - legislation, competitive forces, technology etc are always evolving.  It is getting rarer and rarer to find stable environments in which requirements stay relevant anc complete for extended periods.

I agree that some up front analysis is required - eg understanding the problem domain, business model and top level business process, but beyond that I am very comforable with building and correcting as you go.

Now, my question;

You stated earlier that all things being equal an agile project will spend more than a planned up front project.  Can you share your source for this comment?  If you do I am goin to bait the agile message groups with it.

 

Craig

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Amount of Time For As-Is Modeling?

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...

 



Upcoming Live Webinars




 

Copyright 2006-2021 by Modern Analyst Media LLC