I chatted with my buddy David today about a project he has going with a client to implement a sales solution.  Everything is moving along successfully for David – good news – and there’s a good reason for it.

And that reason?  Well-defined business requirements, followed by technical specs.  Do these activities in detail and well, and you’re halfway towards completing a successful technology project.  Do them poorly, though, and your project is a ticking time bomb.

Business Requirements make technology work for you

Whatever technology solution you implement will only be as good as the processes it’s meant to automate.  If you’re processes are ill-defined, then the value of your solution set will be undermined.  That means that rather than supporting or solving your users’ needs, the technology might instead get in the way or failed to be adopted. 

The other determinant of success for your technology solution will be user adoption.  It’s not enough to make a corporate determination a certain technology is needed.  Your users have to agree to use it.

That’s where the Business Requirements document comes into play.

And what about technologies other than those meant for automation such as web development and design for a corporate site, community, portal, or eStore? The answer is the same. You need to create a compelling experience your users will want to use and it still starts with defining your business requirements.

Business Requirements define how your solution should work

Business Requirements documents are written in plain-speaking and non-technical language.  These docs explicitly define your company’s processes, as well as explictly explain the user experience you want the solution to provide. 

Said another way, Business Requirements define exactly how you want the new or enhanced technology solution to operate.

The requirements may vary depending on whether your project intended for web development or business automation.  Here's a general list we at intellicore Design use when writing Business Requirements docs for clients:

• Project team members and responsibilities.
• Licensing requirements (how many users and what type of licenses are required).
• Process workflows, including any approval processes.
  • Start with explaining existing processes, including what is and is not working (provides perspective).
  • Definition of new processes, including any triggers or approval processes.
    • Using process maps helps clarify process flows.
• Data field requirements.
• Screen mock-ups to provide visuals on the expected user experience.
• Integration requirements to other solutions
  • Including changes to the other solutions.
• Project phases  (if applicable).
• Project milestones.

The secret sauce

Business requirements documents are best when they incorporate a holistic view of your company’s business needs and objectives.  Even if today you’re only implementing a solution on behalf of a single department, anticipate that tomorrow it might go company-wide.  Prepare for the possibility in your business requirements by considering potential requirements for other departments.

The benefit? You’ll avoid implementing siloed technology and pave the way for company-wide implementation of the technology solution sets.  That means you do a better job of containing IT costs.

Technical specs – the technical how to

Once you’ve completed the business requirements, then it’s time to convert the plain-speaking, non-technical document into technical specs.  This is where the IT folks really come into the game.

The Technical Specs document specifies the technical design for impending solution and it serves as the how-to manual for IT to know what and how to develop or implement.  A Tech Specs document includes explicit details about the required technical platform, as well as requirements for databases and connectivity.  It may also include snippets of code.

Time requirements for documentation

Time requirements to prepare the Business Requirements and Technical Specs docs will vary.  With Intellicore Design, I’d say our projects are split about:

• Solution design
  • 30% – Business requirements.
  • 30% – Technical specs.
• Development or implementation
  • 20% – Programming or configuring the solution.
  • 10% – Testing.

Summary

Writing the Business Requirements and then the Technical Specs is where you find the meat of any technology project – and you need to give each of these design activities the time needed to complete them properly.  If you do, then you’re directly increase the likely success of your IT projects.

Update (10/31/09)

You know, it's funny.  I sent folks on my email list notice of this article...and pretty much no one clicked through to read it.

Here's my guess as to why.  Writing business requirements isn't sexy...it's hard, detailed work...and that might be why so many companies fail to invest the time needed to do them well and in-depth.

Here's a big old secret, though.  The quality of your final software solution is directly proportional to the quality of your business requirements.

So...don't want to do those requirements yourself?  Contact me...I'm happy to take on the project for you.  

And Cynthina, my business partner, she'll be happy to take the requirements I dish up and convert them into detailed technical specs for you.

See, these are things we do much better than the average bear.