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


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 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
5th Level Poster

Re: Amount of Time For As-Is Modeling? 


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!!!


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

Re: Amount of Time For As-Is Modeling? 


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? 


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.  


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

Community Blog - Latest Posts

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Analysis. I'm happy to share insights from my recent conversation with Kingsley T. Ihejirika, PhD, an ICT Business Analyst at the Ministry of Justice in New Zealand. Kingsley's unique blend of academic theory and practical expertise sheds light on the path t...



Copyright 2006-2024 by Modern Analyst Media LLC