So you are a business analyst, and you work with SharePoint. The following five questions should come out of your mouth at some point on any project you are involved in. Why? Because they will make you a better BA, and result in a better project, that’s why!
1. “Are these workflows embedded within the organisation already?”
Every Intranet project includes some kind of ‘workflow’ element. This is generally bad. SharePoint is pretty good in this area, and includes some useful prebuilt workflows. If you throw Nintex into the mix you have a really powerful workflow platform. But stop right there. If a workflow isn’t already being used offline (manually, on paper, by people somehow away from computers) it will be really difficult to implement it properly as part of the Intranet. This is especially true if it is a new system. Nine times out of ten you will be biting off more than you can chew by attempting workflows. Wait until the Intranet is embedded culturally, and then start small.
2. “Does everyone in the office have that same requirement?”
Lots of requirement gathering starts in the boardroom, with directors or bosses of a company. These guys typically pay for a project, so want to have a say in how it is built. Fair enough. But these people aren’t always aware of how their company works or runs on the ground. When you collect requirements at board level, be sure to check if the end users agree or have the same experience.
3. “Why do you want to do that?”
I’ve said this before, and I’ll say it again. You simply aren’t doing your job if you are not challenging requirements. Ask why. A lot. Never accept anything at face value, from one source, or without a little digging. A given requirement might be simple, it might be, but more often than not it will be much more complex than it first appears. Asking why will help you uncover this.
4. “What about if we did that in phase 2?”
Intranet and/or SharePoint projects can be very complex. SharePoint is a bit of a kitchen sink product, good (or capable) at a great number of things. This often results in projects that try to do to much. Document management, workflows (see #1), wikis, blogs, news etc. A project that spreads itself too thin often fails, ending up with average (or poor) functionality in a lot of areas. Users just turn off. A good SharePoint BA will try to mitigate this by keeping the initial delivery small, and having off other functionality to a phase 2. Deliver a small tight system initially, and you are much more likely to get and keep users.
5. What is the project plan after ‘Go Live’?
Many SharePoint projects end after the system is launched. Many of these projects fail. The two things are related. Think of ‘go live’ as half way through your project plan. You should be asking the client what happens after launch. How are users being training? How is engagement going to be encouraged, and measured? What activities are planned to keep the system interesting? When is phase 2 happening (see #4). A good SharePoint BA doesn’t stop when a system launches, they see that as the beginning.
What other questions do you think a good SharePoint business analyst should be asking?