Staffing a project that involves SharePoint can be very simple or a complex undertaking. Why? Staffing depends on several variables such as size of the organization, timeline and budget, areas of the business impacted, areas of IT impacted, risk to the organization and culture. You can probably think of some others but these are the typical discussion points that come up in most conversations.
To grasp the complexity think about the undertaking ahead of you:
- Are you a global company?
- What percentage of users are impacted?
- Will there be many applications to be integrated?
- Do you have a controlled vocabulary? Information Architecture?
- Is there a significant amount of data to be migrated?
- Is operations ready? Help Desk?
- Is the infrastructure ready?
- Are you staffed appropriately?
- How many projects do you have on the go today?
- Is the culture ready?
When I think about IT projects these days, I think simplification, centralization, standardization, compliance – on a shoestring budget and compressed timeline with limited or no qualified resources. For some reason, senior management expects IT to work miracles – a death march of sorts. This sort of mandate has a huge impact on IT morale, outcomes and the resulting behavior of these individuals on future projects – how would you feel with a gun to your head?
So back to the task at hand, how do you staff a SharePoint project in a large organization? Well, you require several disciplines to create a team that can execute well. The roles include the following:
- Executive sponsors (Across the organization)
- Regional representation (Business units, IT, contracted third parties etc…)
- Operations (Data center, Help Desk, Management, Day to Day Administration etc…)
- Networks (LAN and WAN)
- Servers (WinTel, Unix, AS/400 etc…)
- Storage (SAN and management)
- DBA (many clients have sick databases)
- Quality Assurance for functionality and performance testing
- Records Management (Regulatory obligations and company policy)
- Information Architecture (The librarians of information)
- Application Administrators (Applications you plan to integrate)
- Developers (People that code)
- Online communications (Branding, communications etc…)
- Project managers and project leaders (Planning, reporting etc…)
- Security (Tools, policy etc…)
- Third parties (Outsourcing partners, application venders etc…)
This is a large team right? Yes, but you could scale this down for small projects by thinking of these roles as disciplines. Specifically for smaller projects you could have a team of multi-disciplined people that take on multiple roles. For example, the SharePoint person could take on Information Architecture, Development, Server and Storage design.
As consultants, we must have a multifaceted approach that helps customers see the ‘big picture’ when staffing their projects. When doing so, it’s also important to understand the various agendas and personalities at play. For example, recently I met with a client to discuss a global deployment and we invested 4-5 hours openly discussing how to approach planning, design and deployment from a holistic perspective. A few days later I received a call from someone representing the same client that was totally out of control – hammering me with questions, cutting me off mid sentence – unprofessional to say the least. Needless to say I was embarrassed for this person yet somewhat sympathetic. Why? Obviously the person is insecure and trying to show value in their own bizarre way.
So back to the task at hand, how do you staff the roles yet make sure the people on the team are well suited to work together? Consider these questions:
- Has the team worked together in the past?
- How did they perform (Type X or Y?)?
- How do they handle stress (Rally the team or alienate them?)
- Was there conflict? Why?
This is where the hiring practices of the companies HR department and project management skills really come into play – when assembling a team. In many cases you don’t find out until the project is underway which needless to say is risky.