Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Business Proces...  Business Process and Documentation Types
Previous Previous
Next Next
New Post 6/16/2008 8:59 AM
User is offline Carl
4 posts
No Ranking

Business Process and Documentation Types 
I just started working for a small IT shop that now consists of the owner the developer and me. The current process is the owner talks with a potential client for 15 – 30 minutes and based on that conversation the owner and the developer sit down and come up with an estimate of hour many hours it will take and then present the estimate to the client. If accepted, then we may interview the client one more time before we create a Functional Specifications document. This is used to obtain client sign-off as well as used by the developer to build from. The Functional Spec is way too detailed for any client to be expected to read and understand, but isn’t quite detailed enough for the developer and certainly not formatted for easy use by the developer. Does anyone have any suggestions for improving the process and what types of documentation we should be using and at what point in time we should be using it?
Thanks so much for any input.
New Post 6/17/2008 4:37 AM
User is offline Craig Brown
560 posts
4th Level Poster

Re: Business Process and Documentation Types 
Modified By Craig Brown  on 6/17/2008 6:38:42 AM)

I think you should basically skip the FD and go for a high level (higher than that) solution architecture and then talk them through the complexity.  Forget the issues of requiremets before solution design.  You are a small and integrated team so should be continously talking.

You should also think about whether you can get sales using an Agile Modelling approach. (Google it of you don't know it.)

Lastly - try breaking your delivery into four (or however many) phases; discovery, planning, delivery, implemntation.  Try delivering in small iterations - that way the client gets to say when to stop spending her money and you get to prioritise high value features up front.

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

Re: Business Process and Documentation Types 

It sounds like you are tasked with process improvement before going into automation.     The UML does not specify any process improvement techniques.    I highly suggest data flow diagrams, espcially if the need is to come up with a comprehensive, integrated whole.  Use data flow diagrams to simplify and integrate.  

To spec for automation, many suggest the UML (use cases and, sometimes activity diagrams, for functional modeling).     But, it has always been my experience that, for larger scale efforts,  the UML techniques fail because they are based on the use of a forced, artificial partitioning and they lack a lithmus test of completedness.  I use a modified version of data flow diagrams for systems design diagrams.  One that substitues, for example, transaction type flows for logical business data flows, and allows for flow of control.



New Post 6/18/2008 5:46 AM
User is offline Nigelus
23 posts
9th Level Poster

Re: Business Process and Documentation Types 
Modified By Adrian M.  on 6/19/2008 1:08:48 AM)

I would suggest a proper business process discovery and documentation procedure and the best and easiest tool around for that use these days is Process Master There is a free download available and it really is the easiest tool to use. You can output the documents as PDF for collaborative use and then perform analysis to the "as-is" with a view to optimising and improving the business processes before automation.

In addition the output of this tool produces an XML file which has connectors for configuration of numerous BPM tools - give it a try

New Post 6/18/2008 11:26 PM
User is offline Adrian M.
764 posts
3rd Level Poster

Re: Business Process and Documentation Types 
Modified By Adrian M.  on 6/19/2008 1:28:03 AM)

 cnsdahl wrote

The Functional Spec is way too detailed for any client to be expected to read and understand, but isn’t quite detailed enough for the developer and certainly not formatted for easy use by the developer.

I'm not sure what "Functional Spec" means in your organization but it sounds like you have a real problem: you have an artifact (the Functional Spec) which is not good enough for either the client or the developer.

What I would suggest is that, if documentation is important to your organization, you split the documentation into two types:

  • artifacts to be consumed by the stakeholders/clients, and
  • artifacts to be consumed by the development/technical team.

Now these can be separate documents or separate sections in the same document.  Please note that I am not advocating that the dev team cannot read the stakeholder artifacts or that the stakeholders can't review the functional specs.  I'm just saying that you might consider having artifacts tailored for a particular audience.  It's sort of like having to give a speech about the scope of the project to the stakeholder and to the developers.  I bet that while the two messages may be similar and have many things in common, they would also be very different as to what is said, how it is said, and how much is said.

Of course, before you make a decision as to what type of artifacts to use you need to also identify the "why" of creating the artifact.  Why do you need the artifacts?

For example, your organization's process might require that a client sign-off is received on the requirements before proceeding with the functional design.  Or maybe the development team is not close to the client and BA and need to have clear functional specs.  Identifying the "why" is very important or else you won't know the reason behind why you are doing what you're doing.

So without knowing much about your project's needs, processes, or structure, here are some options. Note that in most cases you won't need all of them so look them up and decide what will work for you.

Artifacts for consumption by the clients/stakeholders:

  • Business Case
  • Vision Document
  • Project Charter
  • Business Requirements Document
  • Business Use Case Model
  • Business Use Case Briefs
  • User Stories
  • etc.

Artifacts for consumption by the development team:

  • System Use Case Model
  • Detailed Use Case Specifications
  • Functional Specification Document
  • Data Model
  • Data Flow Diagrams
  • etc.

- Adrian

Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 1 Reports
Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Business Process and Documentation Types

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC