SharePoint; the land of the Planner, Architect, Systems Analyst

Geoff Evelyn, FIAP has written here before about aspects of SharePoint. In fact, he might be said to be evelyn-gelical about it. Sorry, I feel better now. This time, he concentrates on staffing for a successful SharePoint project.

If you’re a SharePoint Architect, there are a number of areas you want to focus on. I decided long ago that my focus is implementation, structure and automation of the business process. So I combine my technical knowledge of SharePoint with the project, business and planning skills that I’ve gathered from over 20 years of systems analysis and design.

SharePoint is a collaborative technology. But, after all, it’s simply a system, a software product. That system is subject to the exact same laws, in terms of management, as any other. Therefore, the processes and procedures followed in its deployment will be exactly the same as any other system in that the planning, implementing, deployment and support processes will be ‘standard’.

This system needs to be fully understood by the relevant solutions architect and, as you will have guessed, in this case, that’s a SharePoint architect. This person understands the nature of the beast (deeply), including the format and application of any technologies connected to this system. He or she would also know how to implement features of the product using not just technical knowledge, but traditional systems analysis skills. What?

You can’t be serious Geoff – the SharePoint architect is a system analyst?

Well, let’s look at the key tasks of a systems analyst and see how this ties in with the tasks of a SharePoint architect:

1. Detailing and understanding current business processes
2. Defining requirement specifications to match with defined user requirements
3. Designing, planning and producing a system specification, including rules for management
4. Creating the solution. Yes, the systems analyst could be a programmer too in some circumstances!
5. Implementing the solution, working the life cycle (3, 4 and 5 again and again)

So, we could assume that:

1. A programmer is not a planner
2. An architect combines support, configuration, sometimes planning, even developing
3. But, the architect is not necessarily always the planner

So, let’s go to the planning….

Say that you have been appointed ‘SharePoint Dude’ and are about to embark on installation of SharePoint to an organisation. The organisation will definitely adopt SharePoint but it wants to apply a ‘trial’ platform which is intended to migrate eventually into a full platform. So, making this look scary (but pretty real), let’s say that you are the sole individual set to do this (meaning, that you are the planner, supporter, programmer – hey, I’ve seen this happen!).

Here are the very basic things you would need to do.

1. Gather requirements from the users e.g. site premise, structure, information analysis, data content typing, organisational structure, stakeholder management
2. Design the solution e.g. wireframes, taxonomy, metadata, content formatting, capacity, logical and physical
3. Define the implementation process e.g. procedures, guidelines for use, governance, testing, verification, validation, customisation
4. Design support; SLAs, backup and restore, disaster recovery and business continuity, staffing, training
5. Install and configure Sharepoint
6. Test, verify and validate
7. Train and educate the users

Hey, that looks suspiciously like the Systems Analyst’s work!

As you can see, this is no mean feat for a single individual. If this is not made clear to the business from the outset there will be serious issues concerning the planning and implementation because no one would know the risks involved. Even if the SharePoint architect is also the planner, that person would need to be able to prioritise all the tasks because the architect’s hat will be changed very often! This means frequent re-confirmations with the business stakeholders.

Also, there is a split between what are perceived as technical (server and software configuration) and business-driven (user requirements) needs. Whilst it may be prudent for the SharePoint architect to gather, design, document and implement these, some would argue that it’s very time consuming and difficult to plan and it means all eggs are in one basket. Again, without this being communicated back to the business there will be serious problems ahead…

See where I’m going with this? The bottom line is that the SharePoint architect is not the planner in a large installation or a project where there is a requirement to gather lots of information. But for a small pilot install where the risks are low, the SharePoint architect could also be the planner, though the definition of medium would have to be stressed to the business. And, in my view, there is no such thing as a SharePoint architect in a small company installation …

Bold statements, yes? But, I think it’s key to understand that a SharePoint installation will go out of control without someone to drive the targets and meet time objectives. That’s where the planner / project manager steps in – and guess what – they would know SharePoint.

So, in summary, organisations new to SharePoint who need to improve collaboration, information management and online Web-based communication need to ensure that a SharePoint Architect is provisioned to make it happen. The SharePoint Architect’s task is to ensure that the platform is resilient, performs, meets user requirements and is future proof. The Planner is there to ensure that its implementation takes place on time and, in most cases, to budget. Hence, ensuring there is control and standard systems analysis will ensure that SharePoint is not perceived as a silver bullet but as a tool that enables the client to be more data productive.