Agile Curam Development Requirements Gathering: Working With Your Customer

This is a continuation of my previous post.  In this entry I talk about working with your customer in hopefully an effective fashion.

One of the toughest part in any project, not just Curam, is getting enough information from your client so that the development team can use it and the client won't come back and say, "that's not what I meant."  This may seem like squeezing blood from a stone, but when done right it won't be as bad.

The thing that should help on the get-go is planning and defining who does what.  The other important thing a Curam BA has to do is to help your customer adapt to Curam, rather than accepting everything they want.

Unlike non-Curam projects, this is a lot easier for Curam practitioners as they already have a working product that they can use and play with.  However, regardless of whether it is Curam or not, it is best that the BA works with the application architect to make sure decisions that they make won't have major consequences to the work.

Roles and responsibilities

It is best to determine roles and responsibilities as early on as possible.  Customer business reps should be talking with each other, same with your BAs.  However, one of each side must lead their own packs.

Here are the pair levels:

• Lead pair - talks about the end to end scenarios with each other.  Creates the first workflow drafts.
• Workflow pairs - talks about workflow and activities to a lower level of detail.  Joins with the lead role meetings to get an overall understanding and confirmation on what the scenarios are supposed to be doing.  You may end up with one pair for every 1 or 2 end to end scenarios.
• Delivery pairs - talks about the deliveries that would need to be done and the rules and evidence associated with them.  You may end up with one pair for every 1 or 2 deliveries.
• Usability pair - talks about how things should flow screen wise.  They would also talk about modifications to existing screens to correspond to privacy guidelines.  They would also talk about who would have access to what screens.  This is usually just one pair but works with the other pair levels to understand how the screens would relate to the business.  There may be more than one pair if the customer wants to have a lot of changes done to the screens and security.

If the project is small, which is rare for Curam, some roles may be combined into one person.  On the other hand, if you have a big enough project, it may require more than one person to do the role.

Planning

Now that you know who your resources are, you should be able to create a project plan with dependencies on each component.  This is necessary in case someone misses a deadline.  If a deadline has not been met, then the project plan needs to be re-adjusted as a change request.  Missing a deadline is a change in scope and should be treated accordingly, otherwise you'd end up with scope creep.

I would recommend that you use a proper planning tool such as Microsoft Project or OpenProj (when it becomes less buggy) to help plan things out.

Also you need only to take the detailed plan on the requirements gathering portion.  It is not too bad unlike other areas, because you really have no external dependencies short of the customer.

90/10 not 80/20 rule

You do not have to push the client to finish things before they are done.  Remind them that if they spend too much time trying to get things perfect at the beginning, then they'd cause more people to be idling.  However, they should not leave things to be in an imperfect shape, otherwise they'd still have to pay for any changes to their original requirement once development has started.  It is a balancing act.

Fortunately, the approach I am taking uses the User Story method that they do in XP for most of the work products a BA needs to build.  This approach gets them to say in their own words what they want to accomplish.  These may have already been put into the RFP, but even if it is not then we would have marked the component as high complexity and so more time can be allocated to get the necessary information.  The other nice part about User Story method is the BAs don't have to write long wads of documentation, that task is passed onto the customer, who should know how they want things to work more than the BAs.

Because Curam has done a lot of things for us already, a 90/10 target should be strived for rather than 80/20.  Of course the best way of doing this is...

Adapting to curam

Keep in mind, just because the customer wants something, does not mean that it should be how it is supposed to be done.  Especially with the usability and case lifecycles.

Using a COTS package like Curam implies that there must be some flexibility with the customer to adapt to Curam.  Otherwise, Curam should not have been proposed in the first place and instead a custom solution should be built.

Meetings

The best layout with regards to meetings with the customer and the BA would be as follows

• Monday - All hands meeting, to plan things to do during the week.  BA team then has a meeting with other groups in the project, specifically development.
• Tuesday - Meet up with the customer business rep.
• Wednesday - Meet up with the BA team to make sure everything works.
• Thursday - Meet up with the customer business rep.
• Friday - Meet up with the BA team to make sure everything works.

The reason why it is laid out in that fashion is to give the BAs enough time to prepare for their next meeting with the customer.  Consecutive days of gathering customer requirements would not be the best use of their time because there would be too much things to capture and not enough time to think about what they captured.

Conclusion

A colleague at work was also suggesting I try to write up this series as what "I would like for a BA to give me as a developer" rather than being Curam specific, so I have tried to do above by putting in things that are non-Curam specific.

The following points are not Curam specific:

• With proper roles and responsibilities defined, the risk of miscommunication is greatly reduced.
• With proper planning, scope creep caused by slow customer response is reduced.
• It does not need to be 100% perfect, but don't slack on it either.
• Knowing the technology would help you make better requirements.
• Planning how to meet will help prepare your time for weeks ahead.

In previous projects, I've worked with BAs that give me 99.9% complete and correct specs and I am amazed by the quality.  So at least I had some things to go by. 

It is good that they were helpful about it too, if there was something I didn't understand I just came up to them and they pointed me to the right place to look.

Although I do remember one their comments when I do find something wrong: "We don't like Archie as he reminds us that we are not perfect." :-)

However, reality is what development will actually bring out.  So if I were a BA, I would have to bite the bullet and tell the client about the error.