TechForum

Effective outsourcing - II

In the last article we covered various problems associated with software outsourcing. We also concluded that the root cause of all problems lies in the fuzziness associated with the initial specifications and their real impact on the business.

In this article we will explore various ways and guidelines that can help you in effective outsourcing and in creation of useful applications that really work for business users.

Guidelines

These guidelines are based upon various experiences I have had throughout my IT career. This list is by no means complete. Further, this list is not based upon any established standards or practices that may be already in vogue.

Here are the guidelines and learnings:

The real “Proof of concept”

It is important to make expectations very clear from the outset. Not just with end-users but also decision makers, vendors and IT team.

It is almost unfair (and infeasible) to expect that a new application developed will be the perfect one. In fact, we have to plan with the attitude that the first rollout of the new application will only provide partial benefits.

I would go to the extent of saying that the first attempt of automating/enhancing some business task/process/need is really just a proof of concept.

This is because of a simple reason. Initially, end-users only know what they have been doing for so long. When techies go and ask them specifications for the new application, they simply don’t know what to expect. They do not understand how various technologies are going to actually translate into benefits in their context.

To complicate matters further, technical people keep hammering various types of complex jargon on them. Therefore, most end-users end up providing specifications which can at most be called a wish-list or a fuzzy description of what they think they want and what they think is possible with technology.

Only after the first rollout do they really understand what is actually possible. This is the time they start realising what is possible using technology. After this, their thought process is stimulated to extrapolate further. Now they start asking for real useful features and functionality.

Unfortunately, by this stage the IT Team as well as the vendor have conveniently concluded that the project is over. They look at these requests as unjustified wishes by demanding users.

We need to encourage this feedback post-rollout to ensure that the real demands of end customers are not only accepted but acted upon promptly.

Every application has versions

Most of us think that only so called “packaged products” have versions. Further we think that packaged product vendors come out with versions just to make more money through upgrades.

When it comes to an in-house application, which is never going to be packaged and sold to masses, we think the first rollout is the end of its lifecycle.

This is where we go wrong. As shown in the previous section, this product has just begun to show what is possible to the end users. Their feedback is the only thing that can actually lead to a mature application.

Typically, bug fixing is offered at no extra cost for a specific period after deployment.

However, from an outsourcing perspective, it is also important to allocate separate funds for this maturation phase.

Prototype driven

The earlier you create a prototype (even with bare minimum functionality) the better it is. This prototype must include the visual interface and base business logic.

Unless end-users approve this prototype, further development contract should not be finalised at all.

This eliminates the “I did not ask for this” syndrome, which typically appears at the end of the development. By this time, it is too late to do any kind of damage control because the damage (gap between user expectations and the fully developed application) is already done!

Three-step outsourcing

This is a concept that I have found to be useful in many cases. It is still not widely known or adopted. However, this methodology has substantial merit. It avoids ambiguity, conflict, failures and cost/time overruns.

The idea is simple. Divide the project into two separate phases. Each phase is considered as a separate commercial proposal. Each phase potentially could be awarded to different vendors.

Phase 1

This includes the following:

1. Complete understanding of the requirement

2. Glossary of specific business terms

3. Documentation of the requirement and approval by end customer

4. Quantification of direct and indirect benefits

5. Complete UI design

6. ER Diagram

7. Component design

8. Risk assessment

9. User documentation samples

10. Performance criteria by action/page/report in tangible quantified terms ( e.g. specifying ‘less than 5 seconds with peak load of 1000 users with 2 lakh records in transaction file’ rather than saying ‘very fast’)

11. Deployment and rollout plan

12. Detailed and granular project plan for executing the project. This should include manpower requirements, infrastructure, training and rollout requirements from both parties.

This phase is awarded to the most competent vendor based upon the criteria given below. The costing for this phase is approved separately. Depending upon the business urgency, this phase can be as detailed or as brief as required.

After submission of this phase and its acceptance by the users, the second phase is initiated.

If required, this phase can be awarded to multiple vendors. This way, each vendor is given a fair chance to prove their skill sets.

This phase is executed as a variable cost project on a man-day basis.

Typically, this phase is much shorter than phase 2. Therefore, it is more desirable to execute it on a variable cost basis. If required, you can also put an upper limit to the effort.

Phase 2

This is the real execution phase. Here the deliverables of Phase 1 itself is floated as the RFP.

Again multiple vendors can quote for this. The vendor(s) who executed Phase 1 obviously has a better chance of clinching Phase 2. However, it is not the only option you have.

Now Phase 2 must be executed by the vendor in a fixed cost manner. Most vendors would agree to this because the specifications are much more detailed and specific.

This phase includes:

1. Physical database design

2. Actual coding

3. Testing

4. Stress testing

5. Deployment

6. User training

7. Performance tuning

8. Bug fixing

During this phase, vendors are also asked to think from the user perspective and suggest features that they think can add more value to the application – even if end-users have not asked for it.

These features are expected to be in business language without any technical jargon. End-users must evaluate these feature suggestions. Vendors who have suggested more features that are actually useful for business are given preference over vendors who just complied with the specifications.

Phase 3

This is the maturation phase. This starts only after majority of the users have started using the application.

The purpose of this phase is to provide an ongoing channel for the maturation and integration of the application over time.

The work done in this phase is dependent upon the amount of user feedback received. As this parameter is variable, this phase can also be implemented in a variable cost manner.

Post roll-out audit

This is not a separate phase. It is just a method of cross checking whether the benefits envisaged during the planning phase have really been accrued. If not, we can still take corrective measures to ensure that the desired ROI is achieved over time.

Very often, this phase is never conducted. Due to this, in retrospect, a lot of IT investment sounds to be worthless.

Benefits of this approach

Each phase has its own purpose and benefits. The real goal is to proactively eliminate most of factors that lead to project overrun, failure or conflict.

The benefits are:

1. Phase 1 creates a real, granular set of specification based upon initial, fuzzy set of requirements

2. This leads to a much more accurate estimate of the time and cost involved in Phase 2.

3. Furthermore, vendors quoting for Phase 2 are much more comfortable quoting in a fixed cost manner without worrying about ongoing feature creep.

4. If there are gaps between real needs and the solution, these are detected very early in the lifecycle. This reduces the risk of creating irrelevant applications and the associated wastage of resources.

5. Vendors have a much better chance of showing their expertise and advantage when specifications are crystal clear. This way, vendor selection is based upon their skill set and ability to apply technical knowledge to your business scenario, rather than just the cost advantage.

6. During the first phase, the specifications and features are discussed in greater detail. Many lacunae, assumptions, gaps and misconceptions are ironed out during this phase. Due to this the final specification is much more robust and steady. As Phase 1 uses variable costing, the iterations involved in freezing specifications do not threaten the vendor profitability nor the customer budgets.

7. For Phase 2, the customer has the option of choosing another vendor. This puts creative pressure on the Phase 1 vendors to perform better. Even if a new vendor is introduced in Phase 2, the clarity of specifications ensures that the project is executed smoothly.

Outsourcing checklist

Here is a quick checklist about what should be included in the outsourcing contract. Of course, all these items are not mandatory. Nor is this list absolutely complete. Nevertheless, I have found this to be useful reminders of things to be checked. Please note that I have always been a vendor – never a customer. Still I find it important and worthwhile publishing this content. This is because I feel the industry still needs much more accountability, depth of knowledge and long term focus in order to do even better.

Ensure that the following items are clearly understood, documented and accepted by all parties. In cases where the items are not fully satisfactory at the outset, even the compromise formula and the corrective action plan must be mutually agreed upon.

Most of the items are self explanatory. Wherever required, additional details are explained.

1. Base purpose and impact

2. Functional specs

3. Performance specs

4. Technology choices with justification (pros and cons in case multiple options are available for achieving the same purpose)

5. Load specs

a. Number of users
b. Number of locations / sites
c. Server configuration and sizing
d. Network configuration
e. Simultaneous user load by role
f. Maximum amount of steady state data
g. Denormalized data size (archived records which must still be available for online reporting)
h. Access mechanisms

6. Constraints – business as well as technical

7. Setup and Maintenance requirements

8. Configurable options expected in the application (this avoids hard-coding from the outset)

9. Documentation standards (preferably provide samples to vendors during the RFP stage itself)

10. Ongoing support

11. Knowledge transfer (so that the inhouse team can maintain and enhance the application on a long term basis)

12. Third party audit

13. Acceptance criteria

14. Tracking

15. Reporting

16. Escalation

17. Knowledgebase

18. Tools used

a. Requirement analysis
b. Database Design
c. Object design
d. Data flow
e. Testing
f. Stress testing

19. Project repository requirements (Remember, how many of your applications have undocumented / outdated source code / help files?)

a. Documents
b. Source code
c. Installation guidelines
d. Disaster recovery guidelines
e. Security guidelines

20. Test and live infrastructure specs

21. Rollout planning

22. Risk management

23. Post implementation benefit audit

24. Third-party technical audit (as a mandatory requirement for final acceptance, in addition to user acceptance)

Summary

I know these ideas are very nice on paper but are difficult to implement. But there is hope. Because these are just difficult – not impossible. And imagine the amount of benefits that are attached to all these things. Just try this out at least once as an experiment – the size of the project does not matter. Then you will realise the real value of these ideas.

As always, your feedback and suggestions are welcome.

About the Author:Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in