Introduction
I'm training to run the New York Marathon in November (having rested my muscles for the last 25 years). I run over 35 miles a week and have been training for 4 months–and do you know what? The first mile is always the most difficult!

In my experience the same is true starting a new software project.

I work as a consultant for investment banks in the City of London. My job is to work with clients to define strategic projects in enough detail to enable excellent communications between the business and their supplier (frequently located in another time zone) which removes assumptions and reduces the risk of failure.

We apply a proven approach based on industry best practice methodology–irrespective of project size. The level of detail required is determined by the size of project. The approach reduces the risk of failure but this investment pays dividends on projects over $100,000 or 6 months duration.

The project I am going to describe had 3rd party development quotes ranging from $800,000 to $3 million. As a result of the process we were confidently able to predict that the organisation which quoted $900,000 would be able to deliver because we were able to verify their pricing model at a granular level (by function) and they ticked the other boxes (such as CMMI quality and onshore maintenance presence). This saved the client up to $2 million.

For organisations which don’t have experience of outsourcing software development projects the additional process and cost can seem prohibitive. They need to be convinced of the benefits of the tasks performed in the ‘first mile’ add value. This article attempts to provide the justification.

Global valuations project
I recently worked for an investment bank that wanted to redevelop their B2B web site to improve its usability and extend the coverage from European to global stock valuations–a strategic differentiator from the competition. Most of their systems were commercial off the shelf (COTS) packages. Requests were for small enhancements which were handled locally (by a very competent onsite development team) and didn’t warrant detailed definition.

• They wanted to complete the project in time for end of financial year reporting and felt spending time scoping and defining the requirements in detail would only delay the implementation.
• The company didn’t have experience in scoping large bespoke developments and didn’t know where to start.

These are common mistakes. Projects rarely progress as quickly as the business would like. Internal IT professionals always have a backlog and operational responsibilities. Outsource suppliers need more information before committing to a fixed price contract (which we recommend, to remove the financial risk to the client).

The business was getting frustrated by the internal I.T. department’s lack of progress.

In fact the starting point has nothing to do with technology. The primary objective should be to generate a set of clearly defined requirements for a 3rd party to quote and deliver against (and the business to test and sign off against). Taking time to define the job will save time later on and you need the right skills and process to do this.

Having the right sponsor is critical to the projects success. In this case the Front Office Director was the sponsor. Extremely successful, smart and well respected, his appointment was important because whilst he didn’t have experience of software development, he was able to make logical decisions based on the information presented to him.

In this instance, he took advice from the IT Manager that they didn’t have the skills to deliver the project without assistance and appointed my company (I told you he was smart) as an external team with project management, testing and usability/visual design skills to facilitate the requirements definition and perform the project set-up. I was responsible for programme managing the project.

What are the benefits of a requirements phase?
The top three factors affecting the success of projects are user involvement, executive support and a clear business objective¹ .

In my experience businesses frequently miss the opportunity to use any 'I.T. delay' to set expectations:

• what problem needs to be fixed or business need to be addressed?
• what features (a service the system provides to fulfil a need) are required?
• how to approach the task?
• what are the detailed requirements–business processes (use cases), screen layouts, non functional performance criteria and environment (corporate standard desktop).

In this case, the sponsor worked in a dynamic, high pressure sales environment where quick decisions were made based on experience and gut instinct. He wanted to know why it was worth spending time and money on performing these tasks. Process and documentation was considered to be a constraint, tiresome and boring. He wanted a system yesterday!

We needed to convince him of the benefits of a structured approach.

Like most small to medium sized businesses the client didn’t have much experience in managing large strategic projects. Without a good foundation people make assumptions and the lack of a single, agreed vision can result in total confusion. The project is cancelled because it overruns or the project delivers the wrong solution. Energy is wasted with multiple lines of communication between team members trying to figure out what they think they should be doing and having to repeat tasks because they made the wrong assumptions about what was required.

The major benefit of the following approach is that the business–not the supplier–has control of the project. It saves money and results in an earlier delivery because the job is executed right first time.

The business communicates what functions they want, when they want it and how to approach the development. Defining this in enough detail enables you to estimate the project cost and a good supplier to give you an explanation as to how they calculated their price.

The sponsor also has an opportunity to 'can' the project (or reduce the scope) before incurring significant development costs and visible, measurable progress. Getting this right significantly reduces the potential risk of over-run or over-spend because there is enough detail to size the project.

Breaking this phase down into milestones based on regular deliveries demonstrate progress and provides them with the comfort of an exit route if necessary.

The deliverables from this process should result in a non-technical, self explanatory set of documents which can be shared with the development partner as part of the contractual obligations (and tender process). These deliverables consist of a vision, plan of approach, requirements and governance.

The Strategic Vision
The 'Vision' document identifies 'the need' and prioritises the features. If the project objectives are clear and agreed, or the project is small, this isn’t mandatory.

It:

• Enables buy-in from ALL the team–even those functions on the periphery such as regulatory compliance who might have their own requirements but wouldn't have otherwise been consulted. Involving other business team members and clients invariably generates a more complete solution–for instance, how critical is usability (is the solution pitched at power users or novices?)
• Provides an opportunity to move the 'bells and whistles' to a later project and reduce the project timescales and budget.
• Enables buy-in from the supplier. The people performing the development probably don't have domain knowledge and need to design a solution fit for purpose. The vision enables them to understand the problem better and what stakeholders do.

In our case, the stockbroker felt they already had a handle on the features and data to be incorporated in the solution. Because internal analysts used their own system they knew it backward whereas some of their clients used the system only occasionally or used competitor products instead.

What the extended consultation period identified was the importance of 'ease of use'. A bad experience always deterred clients from returning to the existing site. Usability shot to a number one priority list and the approach was change to focus on usability design and testing around a throw away prototype.

Another requirement was to regenerate the company valuations daily (rather than weekly). This was identified as a significant design and ongoing operational cost for little perceived client benefit so the requirement was dropped.

The Plan of Approach
The 'Plan of Approach' is the project managers opportunity to communicate the timescales, risks, work breakdown tasks (including non development tasks such as user acceptance testing and marketing), roles & responsibilities (business, internal IT, outsource), availability, ballpark budget and assumptions.

Used internally (i.e. not usually shared with 3rd party suppliers), the benefits are:

• Confirmation back to the sponsor about the scope–as important as what is included, what is excluded and what assumptions have been made./li>
• A high level definition of tasks and responsibilities (work break down structure).
• An opportunity to identify risks and mitigation strategies.
• Identify training for internal staff or recruitment whilst there is still the opportunity.
• Deliverables and timescales which allowed the business to understood what they were getting for their money.

At this point in the inception phase the full development cost is unclear (because the requirements haven’t been defined). The approach explains how you will get to that information and the cost of the requirements phase.

The introduction of risk reporting allowed us to highlight potential issues. For instance, we escalated to the sponsor that a key member of the requirements team was unable to commit enough time because of operational responsibilities and so needs to be ring fenced or the project would be delayed. The risk report was also a key part of supplier and internal progress reporting throughout the project lifecycle.

The Requirements
The ‘Requirements’ documentation is critical to agreeing the contract price and includes functional workflows (use cases), non functional information (performance criteria, technical environment), screen designs (primarily for usability rather than visual presentation) and high level technical architecture.

Specifying consistent, verifiable, traceable requirements is up to 100 times cheaper than fixing the application after it is live. Spending time on requirements saves money in the long run.

This set of documentation is:

• Another opportunity to kick non-critical requirements into touch.
• A baseline to enable the job to be sized (cost/effort/duration).
• The basis for the architectural design.
• The basis for a contract with a third party./li>

It also enables traceability between the needs, features and requirements to ensure all needs are covered (and requirements don't slip in without a corresponding need).

We used internal staff to write the functional workflows because of their domain knowledge. These guys were financial analysts and whilst they didn't have experience writing requirements use cases they were very capable of writing clear, concise requirements flows with a little on the job training.

The mistake we made was not to perform a formal peer review of the use cases. Individually they were well written but they weren't necessarily consistent across the functional areas. For instance, uploading users stocks to the web site was handled differently between the reporting and portfolio functions. They were also too detailed. They flows referred to individual field entry whereas we would have been better referring to a screen design. We ended up fielding more queries from the developers and making clarifications changes during the construction phase.

Project Governance
Governance enables the right decisions to be made at the right time without delay. It is a catch-all of communication procedures which enables the project team to communicate with the Steering group and supplier to formally communicate with the client.

Governance includes:

• Reporting lines (Steering group attendance, Project team)
• Change control procedures
• Version control procedures/li>
• Supplier progress reporting format
• Escalation path in event of dispute
• Defect reporting procedures
• Release documentation
• Tools to be used/shared for performing the above

Small organisations don't have well documented process and tend to balk at the cost of this. However, having set it up once it can be reused on other projects. We have a policy of providing our own best practice governance and much of this is free of charge.

Governance is even more important when working with a high quality (CMM Level 5) supplier which will have their own internal procedures and be anally retentive about defect classifications and change request metrics for instance (these are key to an efficient software organisation and their bonus may be dependent on metrics!) Governance sets your standard that they have to deliver to. If you don’t have a standard they will apply their own which might not suit your project. Agreeing these processes as part of the contract will make it easier for the supplier to meet your expectations.

Governance made it easier for us to manage multiple suppliers by obliging them (contractually) to, for instance, report progress weekly, (one day in advance of our call over meeting to allow us to review the report) and report defects to our standard templates and simple data interfaces. We acted as the central repository for defects and our project administrator was able to take defects reported by the web front end developers as XML data issues and bounce them to the database server supplier to be fixed.

Governance allowed us to resolve conflicts without resorting to legal advice. When we came to an impasse about the performance of a function we escalated it to the joint steering group (attended by senior executives of both the client and supplier) to negotiate the solution.

How did this approach go down with the client?
Let's be realistic. The client wasn't interested in how we got there. Did they love the process? Probably indifferent but they loved the result and appreciated we wouldn’t have got there without it.

The benefit of the approach was that this set-up phase enabled them to maintain control through the whole project lifecycle because everything was so well defined from the start. Whilst the client was very cost conscious, they appreciated the importance of the project and paid for the process and experience to mitigate the risks of failure. The additional cost of the structure and process should be considered in relation to the benefits.

Because of the upfront requirements phase and sizing they knew the direct cost early on and had all the artefacts to baseline the project and manage it.

There was certainly a leap of faith involved. However, once you've applied a structured process you wonder how you did without it on strategic projects.

This project took over 20 man years and we cut 130,000 lines of code. The development phase duration was over 1 year. It didn't go without incident (no large project does) but the process made each party take ownership of their part. The suppliers knew exactly what they were getting in to before they signed the contract (they had the requirements, technical architecture, visual designs and their detailed estimation of effort and cost by function). No-one felt the need to be confrontational because they knew what they were required to deliver, to a specified standard and when by (contractually). Everyone worked professionally for the good of the project.

The 'first mile' is difficult but if you can convince your sponsor to invest in this process you will increase your chances of a successful outcome (on time, on budget) and deliver a much better solution.

References:
¹Standish Group. CHAOS 10 success factors