Last time I introduced our project — building an online credit system to approve online b2b transactions — and outlined how we identified the core problem and then selected a Business Rules Engine (BRE) as part of the solution.^[1]  The next step called for getting support (and help) in developing the solution.  Getting support (and help) in developing our intended solution entailed these tasks:

1. Getting signoff from management to support the solution and its Proof-of-Concept (POC).
2. Setting up a team to help make the project successful.
3. Funding the project properly and compensating subject matter experts based on market rates.
4. Setting timelines and deliverables for the team to show progress.

Advantages coming from the business side include knowledge of the Profit/Loss of various parts of the business, experience identifying key variables that drive the business, and a relationship with upper management (solidified by similar culture that provides a leg up at getting endorsements for approval).  A high-level summary of cost-saving opportunities from transitioning to a BRE, along with the projected losses that would arise from remaining at status quo, provided enough justification to get the Proof of Concept (POC) initiated.

We aligned strategic objectives with actual metrics as the success criteria of the POC project.  Note that this is completely different from simply transferring code from one application to another and confirming an error-free transfer.  For instance, the criteria for a successful POC of the commercial credit system I worked on revolved around the business strategy to increase automation and to ensure that approval rates were commercially viable.  Ensuring an almost error-free code transition was not enough since the ability to measure, raise, and decrease approval rates were just as important.

After getting over the hurdle of proving the POC, the next step was to form a team.  As for any large project, key members included business experts (those who possess both analytical and technical skills), developers, business analysts, and testers — this formed a team that ensured the success of the project.  A "can do" attitude, with no fears, combined with trust, respect, and openness among team members should be fostered and embraced to meet the challenges.  Business experts have the most important role, acting almost like CIOs, since the project starts and ends with them; their responsibilities include:  architecting the BRE, testing, directing business analysts, participating in extreme programming sessions, analyzing multiple scenarios, and approving releases.

It is not an easy task to find the right developer — one who fits into the team — because many are accustomed to working from detailed requirements and often have little direct interaction with the business.  Since the business experts would be taking the lead, the developer needed to be flexible and learn the basics of the business, think outside the box — be a creative thinker who could deliver code without having all the details, plug holes when possible, and advise the team of alternative options.

Of all the factors that contribute to a near-perfect team, creating a fun environment is extremely important; this motivates and maintains a creative culture.  Outings after work (and even at times during work, when stress levels are at the highest) were common, to refresh and clear our minds.

It's ironic how funding and deliverables seem to have an inverse relationship — bigger funding equates to shorter timetable.  It would be safe to say that not many projects are getting multimillion-dollar funding, so it is critical to set realistic timelines and deliverables, to maintain positive momentum.  There are advantages to a small team, including being a more cohesive group, having fewer debates, making quicker decisions, and getting quicker approvals.  Since the project had a direct impact on top- and bottom-line results and was key to the long-term strategy, proper compensation of the team was important and needed to be based on market rates, given that this is a very specialized field.

Deliverables were taken seriously as there were costs associated with being late.  For our case, the longer it took to deliver, the more the business was negatively impacted from lost customers or additional losses.  We had an aggressive timeline of six months to get a commercial credit system into production, with coverage starting in the UK, US, and Canada.  The remaining seventeen countries were given a timeline of another six months, with some flexibility to be late for those countries where transactions volumes were small.

The next step after getting support (and help) in developing the solution was to document and code.  This will be covered in the next instalment.

References

[1]  Dencie Mascarenas, "Experiences in Re-Inventing a Business Process with Business Rules (Part 1):  Identify the Core Problem," Business Rules Journal, Vol. 11, No. 12 (Dec. 2010), URL: http://www.BRCommunity.com/a2010/b566.html

# # #