There are many ways to gather project requirements: most utilized are the traditional “post-it” workshops, brainstorming and interviews. But can you be sure that you get the right requirements that solve your business needs when using these techniques? Probably not. 

My own experience tells me that “new” ways are needed for how we gather requirements.

The latest trend is something called innovation games where you play different games to get the right needs, decisions and strategies, but also to improve effectiveness.

This is an area that I would like to learn more about and I will not treat this method here.

If you don’t know how to play innovation games or you believe that this option is too radical for you, there are other options.

The following approach gives the right amount of control to ensure the process goes well. It is important to detect deviations for the business needs quickly, which this method allows. 


  1. Get the right people
  2. Ask the right questions
  3. Organized workshops (or organized tasks)
  4. Slice, Prioritize and Organize
  5. Education
  6. Prototype

Get the Right People

Whatever business you are in, you need to make sure that your SharePoint projects delivers business value in the end. This can be hard and especially so if the project is initialized by IT.

What constitutes business value can only be defined by people who are in tune with what is valuable for the business, i.e. senior management.

They need to be part of the SharePoint project, from the first day to the day when the system is decommissioned. Without their collaboration the SharePoint solution you have will lose business value really fast as company goals and objectives change with time.

I would call this group of people the Business steering committee. (Read more about the committee in my previous article on Human Forces.)

Ask the Right Questions

You need to know what objectives and needs your organization has and what long lasting effects the business wants from the solution.

Ask the following questions:

  • What will be different in the business after the solution is implemented, and why is that important?
  • What are the other parameters, other than the future solution, which adds to this effect?
  • Who are the key groups of users in the business who will deliver most of the effect?

“How” will be answered in the organized workshop.

It is also necessary for the committee to prioritize the following.

There are many models that you could use and I'm pretty sure you can get a good proven model for this on the Internet or by asking your colleagues.

Organized Workshops (or Organized Tasks)

The purpose of these workshops is to take the answers from the previous questions and define what is working, what are the problems, what are the solutions.

Another reason for doing this is to have successful workshops in the next phase of the project to define what applications and features will support the business needs.

The audience in these workshops should be the business steering committee but can also include managers from the line and under. The only criteria is that the audience can take in and understand the effects of the business needs.

To succeed in this workshop there must be a person that can steer and explain the objectives of the workshop to the audience. This person also has to be able to gather all workshop outputs and process them to a specification after the workshop.

You will have at least 2 workshops, one to start it off and one to correct deviations, prioritize and slice.

Whatever model you use to get your needs defined, the bottom line is that you need to know what is working, what is not working and how do you want it to work in the future.

Slice, Prioritize and Organize

When you have worked your way through the first workshop you need to have another one to look at deviations and other questions that might have been highlighted.

The follow up workshop (probably just a few days after) will be used for going through the defined needs with the workshop participants to make sure they still believe in what they came up with. Also if there are deviations, then those have to be redefined or trashed. (Nothing without clear business value will be let through to the next phase.)

In the second workshop you also have to prioritize what is most important out of all the needs. This is an important part as SharePoint projects can get really big and that can cause too long projects. If the project scope grows out of hand and the implementation of the project takes too long, the business needs will have changed before the project is completed.

In the last workshop, project organization and standing organization must be defined. You must also make a draft on your time plan and budget.

It will be up to the committee to ensure that an organization is formed that can manage the project, but also to continue working as governance owners after the project is completed. (Read more about this in my human forces article mentioned above.)


Education is an important part of the process as it helps the people that will prototype to understand SharePoint better and get to know limitations and features. They will also learn about the project phases and what is important and required along the way to deliver a good project and continued governance.


By this time the committee most often feels that they are done with their work, but it is important that they continue being a part of the coming phase even if they not on a full time basis. The good thing here is that they already have given you what you need to transform needs to actual SharePoint solutions and features. But the committee needs to remain to be part of the reconciliations.

Prototyping can be made in different ways, ether on a whiteboard or by actually rapidly prototyping a solution in order to test it.

I would start with the whiteboard, as that is much cheaper and doesn't take as much time. When processes and features are drawn out, then move on to prototype development. 

Another good way of prototyping is using wireframes: they can help you with finding the right processes and at the same time ensure the proper UX.

My prototyping process is so simple. It all starts with a “How”: How do we transform the needs to applications? You will take your solutions and start designing them in a workshop. Use the whiteboard or a projector and PC with wireframe software on.

You need to be very exact in what you draw and design, and remember that this process might cost you lots of development time.

When you feel that you are good with the design of your first “How solution” then continue to the next. When all of them are done then you can start the prototyping. I would suggest wireframing if possible but in many cases the functionality that you create couldn’t be replicated in wireframes.

When your prototyping is done you need to review the prototype. It is important here that the steering committee is part of this as they are the only ones that can tell if this solution will give the right effects.

If the result is incomplete (not working) then continue with a review and design update. If your solution is good to go, then that can go directly to the development team to start to build and test.


What Happens Next?

After you have developed and implemented your solutions (and before) it is important that you measure the effects to see if you have gained business value.

Editor's Note: Frederik Leksell has shared a lot of his thoughts on SharePoint governance

-- SharePoint Business Governance Strategy: An Overview