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
www.betterprojects.net
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.

Tony

 

 
New Post 6/18/2008 5:46 AM
User is offline Nigelus
23 posts
www.altkon.com
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 www.processmaster.com 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
Online now... Adrian M.
726 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

Samuel02
Samuel02
With the advent of modern-day cloud infrastructure, many business-critical applications like databases, ERPs, Marketing applications have all moved to the cloud. With this, most of the business-critical data now reside in the cloud. Now that all the business data resides on the cloud, companies need a data warehouse that can seamlessly store the da...
0 Responses
BPM_online
BPM_online
Bpm'online, a global business software company leading in the space of low-code, process automation, and CRM, will be soon announcing their new company name. The new name will be launched in the sky via a breathtaking skydiving performance involving 160 bpm’online employees, including the CEO. The new name of bpm’online is to be fo...
0 Responses
Heta Raval
Heta Raval
In a current scenario, when you are eliciting software service-based requirements then, you may be able to derive requirements in certain varieties. In the beginning, they can be just functional or non-functional requirements. But when you come across many other requirements as time goes, you can conclude requirements into several categories and wi...
0 Responses




Latest Articles

What’s Missing from Agile?
Oct 20, 2019
0 Comments
John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information te...
Copyright 2006-2019 by Modern Analyst Media LLC