How do you get from requirements to production?

Question

I'm doing some research for an article I'm writing about the process of getting from the requirements to production.

I met with some of my peers last week and they had some interesting ideas.

As a quick background, this company is a small web development agency. They have 2 great in-house business development managers (BDM, some places call this a 'sales rep'), with moderate system analysis skills. There is also one project manager (PM). All of their production work is outsourced (some locally, some offshore). About 70% of the work they do is basic web sites (e.g. business web presence), the remaining 30% is custom web-based software.

The approach they use is like this:

• BDM sells client a web solution
• Business Analyst (BA) contacts client to take down requirements
• BA hands over requirements to PM
• PM organises production resources and delivers work

In this structure the BDM has no BA-like responsibilities. Also, the BA and PM are two different people.

I have mostly worked at small web companies the last few years. The most common process I have seen is this:

• BDM sells client a web solution
• BDM gathers requirements (hands it over to PM)
• PM/BA reviews requirements (may ask for more detail)
• PM organises resources and ensures delivery

In this structure the BDM is acting more like a BA. The PM also serves a BA-like function (the project manager often gets the BDM to ask the client a few more questions).

What do you think of each approach? What flaws and strengths can you see? What other structures/approaches have you worked with, and were they any good?

Answer 1

In my experience, the "requirements gathering" needs a technical person involved from the beginning, and this should start before the sale is closed. There are two reasons for this:

1. It reduces the technical risk of the project and makes pricing it easier, since "difficult" requirements are filtered out or suitably modified before you've committed to a project and a price.

2. Often a technical expert can propose modifications to the requirements that will improve the product and/or lower the cost.

I'm not saying that you need get all the details right before you sign the deal, just that you need to have a general, "arm-waving" set of requirements that everybody's happy with.

As well, ideally the BA is either technically strong or is working with someone who is he does the analysis, again to reduce technical risk.

Answer 2

The process outlined in the question at this point reads like classical waterfall (unless the original poster actually means to only look at what happens before any design and implementation takes place).

You should allow for multiple iterations where you go back to the client and check that assumptions still hold, that you're on the right track.

In other words, allow for the fact that things change and both your team and the customer will learn more as you go along.

So I'd structure the process roughly like this:

* BDM sells client a web solution
* BDM gathers initial requirements (hands it over to PM)
* PM/BA reviews requirements (may ask for more detail)

WHILE PROJECT NOT DONE DO
  * Feature/release planning with client
  * Design and implementation of a chunk of functionality
  * Ask client for feedback
END ITERATION LOOP

Answer 3

The risks are highest at the integration points, the more integration points the more risk of losing information, misinterpretation, etc. I think one big part of the equation is the estimate - at what point is that given? By the BDM? With any project there are a few sponsors you need to satisfy -

• the client, providing them with what they want
• your internal manager, ensuring the work is delivered within budget and to the clients satisfaction.

I'm assuming the basic sites are easy and basically off-the-shelf with minor modifications, the 30% custom jobs require more attention and more upfront analysis. I would recommend something like this:

• BDM/BA perform initial business call/rfp review - to understand the needs, effort, etc. (high level scoping)
• BDM sells client a web solution and informs all of any changes to the scope and/or pricing (I'm assuming with the CEO's approval)
• Business Analyst (BA) and PM contacts client to gather detailed requirements and establish contact persons, high level dates, etc.
• BDM, BA and PM review final requirement, dates, costs, etc. and get final approval from the CEO
• PM organises production resources and delivers work
• BA reviews final product
• BDM reviews final product
• delivery to client and post live follow up by the BDM (looking for more work)

There's overlap which provides for more of a warm hand off, reducing risk of the overall delivery.

Answer 4

Read about the different models for software engg. Iterative model is what is currently used in many flavors and comes disguised in many different names. Read Software Engg by Pressman or by Ian Sommerville. That should be a good starting point.

Answer 5

In my experience the best approach sits somewhere between the two. Focusing initially on requirements gathering the key factors here are:

1) The BDM has to do some level of analysis or he's going to shaft the development team or the client. Without a solid scope the price, delivery estimates and so on are likely to be off one way or another and either the devlopment team will be flogged to death delivering it or the client will be hacked off when they're asked for more cash or get less thant they thought.

BUT

2) The skills needed to be a good BDM and a good BA aren't the same. There is overlap but not that much and in my experience most BDMs aren't as structured in their thinking as you need to gather solid requirements and nor are most BAs charming enough to open doors. This means that if you ask the BDM to do a BA role (or vice versa), they're going to be sub-optimal in one area or the other. I think this is especially true when dealing with outsource providers where you really need the scope and spec to be solid.

The way we got round this was the BDM was given the task of defining the scope but gave them a very structured framework in which to do it.

Working with the BA and the developers a check list was developed which would allow the BDM to determine the key factors which would influence the complexity of the project. For a web project these might include high level sections of the site, data volumes, whether login and customisation was required, any third party interfaces, whether it's technical, technical and branding, hosting and so on - you'll know in your own business what these factors are.

This serves a number of purposes:

• You can see whether it is a basic web presence (and indeed whether the people involved mean the same thing by basic web presence) or something more;
• It means that the initial estimates, timescales and resource plans are likely to be more accurate and you can append them to the commercial terms as the basis for the estimates to provide some contractual cover (though because the client has signed off on them it's less likely to be an issue);
• It gives the BA a starting point and prevents him having to have the client repeat everything;
• You're not having to cross train a BDM to be a BA.

Note that this isn't analysis - it stops way short of anything you could code against, but it's aimed at stopping the worst problems you might run into and getting a common understanding on the key elements as early as possible.

Once this is agreed a specific BA can move in and start defining the detailed requirements.

The BA/PM dilema is similar but less pronounced. They are specialist skills but I've seen people act in a joint BA/PM capacity with more success than in a joint BDM/BA capacity. Whether you separate this out comes down to size - of the project and the company you work for.

If you can have specialist PMs and the project justifies it (I'd say the benefits kick in somewhere around 50 man days work) then great, do so, but for smaller projects a solid BA can usually handle the delivery and client management and you might even find that they'll do so with less overhead (you're not charging needlessly for two people to sit in a meeting, read reports and so on). What I would say is that if you're going to expect a BA to act as a PM then make sure they have the time available - while there is overlap it absolutely takes more time to do both than just to do one - and give them some PM training if they need it and don't just assume that they know what's important.

Once it's done it gets handed back to the BDM who continues in an account management role.

Answer 6

We rarely used or BDMs to perform any function beyound sales & relationship management. Our BDMs were responsible for makign the initial contacts and selling the client on our servicescompany. Once we determined that we had a potential sale on our hands we paired up the BDM with an analyst, someone that was very good at extracting requirements from the client (what they asked for was rarely what they wanted or needed) and then hearding the appropriate resources to estimate the project with reasonable accuracy.

• BDM initializes projct, determines if there is a potential sale
• BDM & Analyst jointely engage customer in requirements analysis
• Analyst documents requirements, prepares estimate
• BDM uses estimate to prepare quote (and negotiate in some cases)
• Upon approval, PM is assigned to take over project (project follow appropriate development life cycle - this is a bunch of steps)

A variation on this which we found to be highly effective for larger projects was to sell the client a discovery phase in which we would get paid to do the analysis. Upon completion we would deliver full requirements and a quote to perform the rest of the project.

Answer 7

Just to add a bit to thomanil's answer, and something I have not seen mentioned yet in this thread is finding a way of making the requirements useful for the developers.

I've seen things go much smoother when you are able to take the requirements and extract test cases and test plans, desired screen shots, reports, etc from them BEFORE doing development - customers can see what you will (and won't be testing), and should gain more confidence that the requirements are being addressed - this way you after development, after changes, etc. you can do the testing and say to the customers that you are confident that you are "done" and things look good.

(above I'm also thinking and trying to address that requirements are never really final and that documentation to capture them can get out of date pretty easily)

Answer 8

finally done writing the blog article.

its here if you want to read it:

http://pm4web.blogspot.com/2009/06/from-requirements-to-production.html

ive incorporated many of the ideas discussed here (plus added some new ones).

thanks to everyone for their contribution.

• LM