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/19/2008 5:52 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Amount of Time For As-Is Modeling? 
Modified By Craig Brown  on 9/19/2008 7:54:06 AM)

 ajmarkos wrote

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?

Tony

I have been reflecting on my work experience. Over the last few years all of the major projects I have worked on have been follow up attempts to other people's failures.  As such there has been reams of requirements avaialble.

(Minor projects being minor have only received a small amount of planning time anyway.)

In almost every instance my response has been to abandon the  requirements that went before and start afresh, with only a short period of requirements gathering.  Usually 3-6 weeks.

Each project has been successful; under budget, aead of schedule, higher that expected return on investment and ended with improved relations between business and IT.  I do take some of the credit for this.

Most of these projects have been deliverred in a framework like Waterfall, Prince2 etc.  Look me up on LinkedIn and see who I have been working for.  You'll recognise the national australian brands.

They key is getting the top level stuff right, and then managing everybody into the constraints rather than letting all the stakehodlers ask for whatever they want.  The target is the first release.  once that is in place you have earned the credits to extend the system in the appropriate and valuable areas.

And - Data flow diagrams are a key aprt of the modelling effort - but only high level.

 
New Post 9/19/2008 2:11 PM
User is offline Irene
31 posts
9th Level Poster


Re: Amount of Time For As-Is Modeling? 
Modified By Irene  on 9/19/2008 4:20:12 PM)

I went through the posts in this thread, not sure if I get everything. And thank you Adrian for your response to me in another related thread! I read the 3 articles you recommended, tried to discuss it with my coworkers here and have been trying to read some articles about Agile methodology. I know I may still have a lot of principles of Agile that I have not got yet. Here are some of my thoughts in those several days. Any opinions are appreciated.

1. Collaboration

I am all for more interaction and collaboration of business and development teams. I guess that is also one of the kernels of Agile. I actually think for any projects, no matter which methodology the project adopts, both IT and business sides should work together as more as possible. Programmers should be able and allowed to talk to business representatives or end users directly to get information s/he needs. One of the main reasons for failed or not-so-successful projects is lack of communication and involvement of business and end users. I guess the problem and reality for many projects is company can not afford to collocate and have the business team and development team sit together. Or even if they are physically at one floor or in the same building, business people can not allocate that much time for different IT people to constantly ask questions or they repeatedly answer the same questions. In this case, the more traditional requirement collecting methods might still be the main approach. Having said so, Agile approach does remind those more traditional practitioners including myself, that the importance of more collaboration and involvement of business users. From our IT side we, BA/BSA in IT team, need to present end users the detail requirements, functional specs, mock screens, and not-so-final-yet application periodically and more frequently to get their feedback, to make sure the application which IT team is developing is what they want as early as possible and as much as possible.

2. Change Request Control

Now another piece of thoughts come to my mind. When we have more interaction with business, mostly likely they would have new ideas or even contradictory thoughts on previously agreed requirements. Should we still have change request control? For Agile approach, it seems that the change request control is not as important as traditional methods. I agree that in order to save time, depending on the severities and influence, not all of the changes need to go through the whole formal and slow process. But I still think for most changes, a centered person or team (ex. BA) should be responsible to analyze if necessary, decide and control, in order to make sure the change is within the scope, within timeline, within budget, consistent within the system and not affect the architecture or infrastructure of the system. And also I think all changes, although it might not need to go through formal Change Request Control process, still need to be documented; related requirements need to be updated.

3. Detail Requirements

Now my 3rd piece of thoughts. Maybe I miss something here, I am not sure if I agree with Agile principle on that detailed requirement or functional specs are not as necessary or costing time. Detailed requirements are actually very important in terms of application maintenance, getting common understanding among all parties, etc. If we don’t do detail requirements or do very little, it might save some time at the beginning and developing stage, but it causes a huge time wasting for later maintenance, and easily causes communication confusion, especially after years’ running and possible turnover of resources. This is also one major cost for many projects to do the as-is model when it needs to be upgraded. So it is better we spend some time right now when we have better and clearer information to document, rather than some people spend much longer time to figure out what it does many years later.

4. User Stories or Use cases

Similar to my 3rd piece of thoughts above. I understand for most users it may be just easier for them to understand user stories. I think it is OK to use either user stories or use cases to communicate with business users, or to use user stories as the 1st step, depending on the project’s management and business analysis process. As I mentioned above, I think we still need to use detailed requirements or functional specs to define how the system should be working. Also I suggest presenting detail requirements or functional specs to business users including screen mockups, although some users might not be patient enough to read though. I especially like to show them the screen mockups since I believe screen mockups give them a better and direct vision of the system; and it is also a good chance for them to verify the system.

5. Finalized Requirements

Lastly, I like the idea from Agile that we can not wait until we get the “finalized” requirement to move to next phase. After a certain point, we need to start our system designing and coding. Changes could be done with a more flexible change request control.

To wrap up, I think we can adopt some agile idea to improve our current process or a certain period of process of software development. Waterfall can be more agile. But at least for now I am not sure if all projects at current stage and in current environment can purely adopt Agile methodology.

I appreciate any comments from anybody. I would appreciate more if you would also like to correct my English and tell me some better ways to express. :)

Thanks, - Irene

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




Re: Amount of Time For As-Is Modeling? 

Irene,

Great post and agree with just about every point you make. The phrase you used a couple of time "agile waterfall" I think is interesting but bear in mind Craig's comments earlier about the Agile manifesto which values action over planning (not instead of, just over). I googled "agile waterfall" and there are 8,480 hits the top one being this agile-waterfall co-operative. I have already speculated about a BA method jargon generator and I am beginning to suspect there are no new combinations out there (competition! Find an approach and method that has NOT been combined!).

Of course we need to do analysis and document and verify it - it is obvious unless we are just going to guess at the solutions - so the debate is about how to do that and all these methods and approaches are doing is (I suspect) trying to find a way of doing analysis without the effort of actually doing analysis. Humans don't like analysis I think, and these methods and approaches are our ways of trying to get round having to do that. Agile is the latest and greatest - is it the last in the line of these approaches? Only time will tell for sure but if I was a gambling man (and being a BA I am most certainly not) then I wouldn't bet on it...

Your English is fine by the way and communicated to me all your points or managed to miscommunicate them in such a subtle way I am not aware of it!!!

Guy

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




Re: Amount of Time For As-Is Modeling? 

Irene

it strikes me that you are applying the agile principles already.

On point 3 -

I think the more balanced view from agile practitioners is that you only do the analysis that is required or sufficient for the job at hand, and that if the project requires it (for clarity, assisting developers understand the issues, to manage risk, etc) go ahead and do them.

I guess the issue most good people have is with the template zombie approach to requirements specifications.  As much as we eschew it, it is still style of the vast majority of requirements documents.

 

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


Re: Amount of Time For As-Is Modeling? 

Craig:

Thanks for the informative response!   3-6 weeks to come up with a high-level but accurate understanding of essential functionality and there interrelationships - thats great!   On last integration effort that I lead (corp wide Webshpere at a very large U.S company) it took me three weeks just to get a desk and a PC.  

Tony

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

Community Blog - Latest Posts

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC