The thing I love about twitter is that we get to have great conversations with people who are passionate about a subject in the same way we would over a beer.  Take for example the conversation I stumbled upon on the evening of 15th April..

Richard Harbridge was looking for a decent template to capture SharePoint requirements to which 21apps own Ant Clay responded:

Ant was referring the the 21Shift Model where we focus teams on outcomes.  This started what turned out to be a very lively and ultimately agreeable discussion

Richard responded with the idea that requirements were a journey, an opportunity for Shared Understanding and more than just outcomes.

At this point there was agreement in that we needed to get a Shared Understanding, but a clear view from Ant that Requirements documents were not what was needed; and the journey was absolutley part of the the process of defining outcomes and being able to track these back to the vision.  Requirements documents carry too much baggage and tend to focus on stakeholder ‘wants’

Dux joins the conversation, noting that ideally requirements should not be a document of ‘wants’ which, and I think this is shared by Dux as he used the ‘ideally’ word, is often not the case.

I joined in the conversation to reiterate where we (21apps) see the value in aligning the organisation vision to measureable outcomes mapped to a solution, which some may choose to document as Requirements.  This was in agreement with Richard in that there needs to be a journey in order to get Shared Understanding – but I disagree that Requirements collection facilitate that journey in and of themselves, and as Ant pointed out more often than not they result in a lack of alignment to a vision or worse a list of technology features with no coherent view of what the goal is.

The conversation, as is often the case with twitter chats or conversation over beer, went on to talk about the baggage that is associated with terms and how words like Requirements or Project Management can carry a lot of implied meaning.  Something for another blog post perhaps, for this post I want to reflect on Requirements and why we don’t need them!

But we ended with agreement that we are all on the “Same Page”, and that the journey, discovery and Shared Understanding are the essential elements.

Which is why I reiterate that Requirements – we don’t need them!

What no Requirements?

My background is in development, I worked with eXtreme Programming in early 2000 and have used agile techniques ever since.  The benefits of agile development over the traditional waterfall approach has been debated long and hard and its generally accepted that adopting agile approaches lead to delivery of solutions much more closely aligned to what the business needs.

So why do I think that we need to move on from the use of Requirements in our SharePoint Projects?

The Waterfall Model

http://en.wikipedia.org/wiki/Waterfall_method

Right there at the top of the Waterfall Model is the Requirements step.  This is where, in the waterfall approach, you write down everything it is that you want from the system and then this is fed into the next steps until it ultimately is delivered.

The problem with the waterfall approach is that it assumes you (and I mean the users, managers, business) actually know what it is you want.  What actually happens is people are given ‘one shot’ at getting their requirements written down before it gets taken on by the SharePoint team to build and configure and six months later presented back to the users as the solution they supposedly asked for.

Most users will never have seen the version of SharePoint being deployed, they won’t really have had time to think about what they want to use it for or how it could help them change the way they work – how do you expect the user to be able to write down their requirements?

Even if you are an experienced SharePoint consultant it is hard for you to be able to get the users to articulate exactly what it is they need – you and the users will find it hard to be on the same page.

A warning: Often you will attend meetings where the technology solution is discussed, agreements are reached and everyone is happy with what’s being decided.  A good SharePoint consultant will be able to ensure that the solution doesn’t have any horrors, but they will often get carried away by the desire to cover all of the product features and forget about the real goals – it’s not their fault Microsoft themselves promote solutions based on product features.

Lack of user involvement traditionally has been the No. 1 reason for project failure. Conversely, it has been the leading contributor to project success. Even when delivered on time and on budget, a project can fail it it doesn’t meet user needs or expectations.

Project Management: Criteria for Success – Feb 2001

Lesson from Agile

A lot of what I will cover here is based on a great post by James Shore, Agile Requirements Collaboration. James talks about this with regards to software development, which is where a lot of the innovation and mainstreaming of these techniques has developed, but the concepts are equally valid in SharePoint projects and form a basis of our 21Shift Model.

In agile projects, be they Scrum or otherwise, we refer to ‘requirements’ as stories.  In the 21Shift model we also use the term ‘outcomes’ – the stories define the outcomes that we use to measure the success of the project.

So where do stories come from in the first place? Well… somebody makes them up. Somebody has to have a vision of what the product is going to be. On an XP project, that person is usually called the “on-site customer.” You’ll also hear terms like “lead customer” and “product manager.” or “Product Owner” in Scrum.

This is the first and one of the biggest challenge we face on SharePoint projects, in fact a lot of agile development projects also face this problem.  Who is able to be “Product Owner”

The product owner needs to have a strong, clear vision of the solution, but that doesn’t mean he or she is solely responsible for it. The product owner will work with interaction designers, business analysts, real customers, marketers, users… Ultimately, though, somebody has to coalesce all these conflicting views and come up with a clear, unifying vision. That’s the role of the product owner.

The Product Owner needs a clear, unifying vision.

In order to define the outcomes, or requirements if you insist, the Product Owner needs to have a clear vision of what it is the SharePoint project is going to deliver. They have to work with a diverse group of people and ensure they have a Shared Understanding amongst all stakeholders so that they can define these outcomes.

See the SharePoint Governance and Information Architect Master class for ways to get that Shared Understanding and the Vision stage of the 21Shift Model

Iterations

Unlike the the waterfall approach we do not expect the Product Owner to define all of the outcomes upfront, the solution should be delivered in an iterative approach adding value to the solution in manageable chunks.  Why is this so important?

In waterfall we expect all requirements upfront,  but how can you expect a user to tell you want they want when they don’t know what they want?  By using an iterative approach your users get to see the solution as it’ develops, this results in a great understanding of the solution but also the problem they are trying to solve.

The high level vision could remain the same, but through each iteration the details of how to achieve that vision are discovered.

This brings us to the idea of “latest responsible moment.” “Latest responsible moment” is a core agile idea. The term comes from Lean Software Development. The idea is that you want to put off decisions as long as you can: to the latest responsible moment. But it’s the latest responsible moment, not the “last possible” moment. That wouldn’t be responsible.

The reason we do this is because putting off decisions is cheaper and results in better decisions. Money we spend tomorrow is cheaper than money we spend today, and between now and tomorrow, we’ll learn more things about our environment and the decisions we need to make. Plus, things could change so much that the decision isn’t relevant any more. If we’ve spent the time and effort to make the decision, that money is wasted. So we wait as long as we responsibly can.

Focus on more detail over time

The diagram above I have heard referred to as the “Cone of Uncertainty”,  the further away from the delivery of the solution the less certain the Product Owner is about the precise details needed to implement the solution.

As an example:

Vision:

The Vision could state that we need a consistent approach to project documentation across the organisation to reduce rework, improve quality and align our delivery to the professional image we aspire to.

Outcomes:

We understand what it is the business needs, avoid technology discussions, and focusing on measurable improvements.  This stage really does help with an Retrun on Investment (ROI) needs.
In this example a measurable outcome could include (avoiding platitudes):

• 80% of  project documents based on the correct template.
• 50% decrease in the time taken to locate previous project documents based on similar technology.

Solutions:

As we move into the solutions stage we could identify that we needed to have standard document templates, with defined metadata, that are managed centrally and used for all projects and that the refinements are reflected in search centre.

Delivery:

We need 5 document templates, 8 metadata columns defined, any integration with the actual document template, perhaps use of a content type hub for central management and a policy around the use of the platform. We also need to develop features to configure the project templates automatically.

What this allows us to do is break the solution down into manageable iterations, where the specific details around each of the areas of the vision are refined in greater detail as they get closer to the actual delivery.   The Product Owner is also closely integrated with the delivery team so they can actually see what the solution will look like, how it actually works in SharePoint.

Traditionally agile teams have worked from a Backlog, a list of stories that define the solution, and as they get closer to delivery more detail is added.  In the 21Shift model we have found that reviewing the vision and outcomes for every iteration ensures they still apply, but also to keeps them fresh in the teams mind.

By working at the “latest responsible moment” you can avoid the need to write long requirements documents and allow the Product Owner to refine the details from Vision to Outcomes, with details added as the solution is defined and delivered,  before moving onto the next iteration.  Thus avoid the need for Requirements in the traditional sense, and relying more on the use of stories and collaboration.

Conclusion

To summarize, you need a visionary product owner to work with your team. If you have one, you don’t need to define all the details of your requirements in advance: you can wait until the last responsible moment. If a release is more than three months away, all you may need is a vision for that release. Up until six weeks before implementing a feature, a basic description of the feature on a card may be enough. You’ll need stories for planning about six weeks before implementing, and once you start implementing a feature, you should specify it in detail.

By working in iterations, understanding the vision and defining measurable outcomes it is possible to deliver solutions that the meet the users needs and expectations and align the to vision for the organisation.  All without the need to write Requirements documents in their traditional form.

In SharePoint projects this iterative approach allows us to make much more use of the out of the box features and functionality, we can keep things simple and also have the ability to stop early if the solution is good enough.