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/17/2008 7:40 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Amount of Time For As-Is Modeling? 

Craig,

I have some comments on your comments and an answer to your question (but you may not like it!):

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.)

GB: An Agile development does MORE analysis over the life time of the whole change project as for each release it will have to come up with rationale for each chunk in terms of smart objectives (no smart objectives why bother doing the change?), requirements that deliver those smart objectives, process and data requirements that enable those requirements, non-functional requirements defining the security, performance, volumetrics etc of the processes and data, impact analysis of the solution on the business, analysis of cutover processes and procedures, analysis of test cases to prove that UAT tests that requirements are delivered.

So if you look at the complete change then it is more costly in terms of analysis. And I repeat an earlier point: 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.

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

I would prefer to fix the problem at source and do the analysis correctly.

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. 

GB: Prototypes for me are a tool to validate and confirm requirements, nothing more, and are always paper based mock-ups. If all Agile does is provide a method for validating the products of up front analysis I am a happy bunny. I suspect it isn't and so I am not hopping for joy...

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

GB: As Tony put it: “To quote Einstien:  Never confuse motion with action.” To quote me: “Project expend least time on the area where most errors occur and that cost most to fix.

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

I would prefer to fix the problem at source and do the analysis correctly.

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.

GB: I’ll see your maxim and raise with “more speed less haste” and “act in haste, regret at leisure” and “there is never enough time to do the analysis and always more than enough time to cast blame when things go wrong”.

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.

GB: That kind of predictable churn good – requirements changing on a daily basis, bad. There is a reason for that sort of volatility and that reason should be incorporated in to the analysis of requirements. Whatever, requirements churn is not a rationale for acting without analysis, in fact it makes the case for more analysis in terms of impact.

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.

GB: Please don’t ever be involved the analysis of requirements for a plane I fly in – but you should get heavily involved in the Death Star project you proposed as I am sure Darth and the Emperor would be happy with a trial and error approach!

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.

GB: See above: I analysed it and thought it through. I don’t have any official stats but give me 5 years and when the Next Big Thing comes along, it will provide the official stats…Compare the same project that is developed and implemented two different ways: waterfall and Agile: the basic problem with Agile is economies of scale: you have to repeat all the project steps (project set up, analysis of objectives and requirements, solution design, development, coding, testing, procedure redesign, training plans, cutover procedures, data migration, etc etc etc). Agile has advantages as it minimises risks on a chunk by chunk basis but as with everything there is a price to pay, and that price is time, effort and money, and increased risk! The risk increases over time because of the risk that after 100 small changes for one big project 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.

Bottom line: Agile has uses and so does waterfall and so do JAD, RAD, Lean, Extreme and any other 101 methods and approaches. However, none of them have (to my satisfaction) got rid of the need to do up front analysis...

Guy

 
New Post 9/18/2008 7:18 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Amount of Time For As-Is Modeling? 

Craig:

You stated that:

"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."

Question:

In your experience (not what the books say), how often does it occur in software projects  where up-front, at the start, with a relatively little effort, someone - anyone - is able to come up with a high level, but accurate as-is model -  accurate enough for the project to proceed with incremental development and not result in total chaos?

I have never experienced such, and I have worked with people from coast to coast.      It is often espoused that projects can just create a context model and then move right on to use cases.    In the real world I have never seen this work, no matter how much emphasis is placed on doing such by management.   Nobody that I have ever know - including top management - has had the ability to contribute such to the project.   From what I have always seen nobody ever has anywheres near an adequate up front understanding of the big picture.

This is an important point, as one of the "givens" for sucessful agile projects that Scott Ambler mentioned in his article is that the organization is focused on the essential high - level requirements.    It has always been my experience that such is far from being a "given".

Tony

 
New Post 9/19/2008 3:44 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Amount of Time For As-Is Modeling? 

thanks for the feedback Guy.

I think it is easy to get stuck at polar ends of these discussions when there is lenty of practical useable space in the middle.

 

Juts posted this at Better Projects.

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




Re: Amount of Time For As-Is Modeling? 

Craig,

I read the post at Better Projects...I think it is a good reflection of how things are. People like Agile because of the perceived speed to market - but as Einstien (and no doubt Tony) would say "speed is relative"! In this case, relative to delivering something and delivering quickly. Whether it is the right something or not Agile debates in another day, another release...

Your point about focusing on the polar projects is well made - these are the minority of projects and so don't warrent the majority of consideration. Your graph suggests using a mixture of Agile and Traditional (waterfall?) approaches for all other projects. How would that work in practice?

Guy

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




Re: Amount of Time For As-Is Modeling? 

If you forget XP, Scrum, TDD etc and go back to the Agile manifesto you'll find they are principles that can be just as easily applied in any development process.  They are, after all, principles.

I think there are two (plus 1) key things that can be picked up and applied to any project above and beyond the others;

1. focusing on value, and

2. Do the right things to deliver outcomes to your client (implies don't do the wrong things and aka the common sense rule.)

3. Maybe a third thing is go for an iterative (or multiple) release approach.  Prototypes, refactoring, product extensions, etc. All provide way points to measure progres and align your work to the client's goals.

The manifesto is here.

THe guts of it is reproduced below;

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

 

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

 
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