What was the issue?
An outsourced SharePoint project had hit difficulties. The key issues apparent were low confidence, fear of failure, no user buy-in and looming deadlines. Two months before the project was due to be delivered, the program manager realised it was going to be a failure.
After reviewing what had been produced in the previous 8 months, it was clear that the focus was totally on user interface and user experience. The third party had carefully created a beautiful replacement for a SharePoint user interface, without developing any new business functionality.
What benefits were delivered?
We ran a rescue/requirements activity using in-house knowledge only, which challenged the project team to deliver one piece of useful functionality directly to the users, in two weeks.
This exercise helped the team to focus on delivering useful, useable functionality to real users, and how to engage with users to understand requirements and evaluate prototypes.
- SharePoint is a pool for internal business people to use in their teams
- SharePoint is not about long, outsourced development
- Requirements are written as clear statements of need – they don’t describe a solution
- Requirements can be measured and met
How were they delivered?
There was one month remaining, what (requirement) could realistically be achieved in that time?:
- Multi language publishing workflow support? No.
- Developing a comprehensive taxonomy for the classification of publication and contents of the SP site. (Taxonomy is a vital part of planning a SP implementation) No.
- A forum for stakeholders to contribute their thoughts on how the division and structure of documents might look as the first step towards understanding the classification of documents? Yes.
- Is there a simple technical solution readily available to support this? Yes.
Storm helped the client to see that their project had derailed because there was no clear understanding of their requirements:
- There was no measure of what the requirement would do once it had been satisfied.
- There was not sufficient explanation to the client about how much delivering each feature might cost, relative to other features, so the client was not given the opportunity to prioritise base on costs/benefits.
- There was insufficient dialogue with the client to explain the relative resource cost of 1 potential solution versus another. Which prevented the client from making business decisions/cost benefit comparisons.
- Nothing was ever put in front of users, so the users were not involved at all. There was no measure of whether solutions being developed would even be fit for the purpose.
What were the results?
The plan for project rescue in this case was to use the opportunity of the training course to agree a rescue plan. Step 1 had actually taken place a week before by admitting that the project was in a state of failure (Big step!). Step 2. Use 1 or 2 stripped down Agile techniques to start the process of building a culture of success.