Evolving the Role of the Strategic SharePoint Framework

Back in 2003 when I first encountered Microsoft SharePoint (SPS 2003) as a Director of IT, after a decade designing international Novell Directory Services, it was clear to me that no one really knew what SharePoint was and how to make best use of it. Some said it was a document management system, some said it was a content management system for portals, some said it was whatever I wanted it to be as there were so many features available. I wanted someone to tell me what to do with it. Just like a CIO would, I treated it like an application and had it installed as an application by a technology team. Then what? No one knew what to do with it, Microsoft had no business blueprint and the solution integrators were reliant on us telling them what we wanted to do with it – to be honest we had no idea really, although the features were truly revolutionary from what we witnessed. So commenced the long process of learning how to approach the subject of SharePoint, and indeed enterprise collaborative systems in general.

From the beginning it was apparent that with an enterprise platform that was as diverse and powerful as Microsoft SharePoint™ that it was not the responsibility of Microsoft to develop a business blueprint as the platform could do many things in a thousand different ways. It was for the product to evolve across the global corporate landscape and find its niche. In fact it would later transpire that though many treated SharePoint as a development platform, it was indeed being used for exactly the same solutions the world over, time and time again, due to what it was most capable of delivering aligned with what organisations shared as common priorities, goals and ambitions. What would happen if all these common solutions were brought together in a single, uniform and cohesive plan I wondered and if so was there a logical sequence to deliver these aspirational services whilst avoiding all-too-common pitfalls?

It was similarly clear back then that SharePoint was always pitched by technology staff using technology language to technology audiences. Where were all the business users and business engagement? Where was the use of comprehensible business language? Where was the interpretation of technical features as plausible business services? Where were the business-focused presentations? It was down to me as a business-focused director to fulfil that role myself to my own business stakeholders and do the translating. Evidently then no one had thought that there was a requirement for a business driven engagement role, a role for someone to bridge the gap between the business and technology. This is the origin of where the role of the SharePoint business strategist started to evolve in my mind.

By 2005 I had delivered SharePoint in a structured format to 22,000 users and by late 2006 had moved as a Microsoft early adopter (RDP & TAP) to the next version of SharePoint (MOSS 2007) with Microsoft case studies and interviews to match. By now it was clear that without a logical business framework or roadmap to work against SharePoint could be too confusing to any client. I was already advising numerous major organisations by then who wanted to know “how I had got it right’ and I gave them the benefit of my advice in my straight-speaking (I was even presenting for Microsoft on the subject) but there was still no diagrammatic method on the market.

By early 2007 I had taken my early thoughts about common services and designed a uniquely structured modular framework that I named Sequenced and Logical Enterprise Methodology (Salem™). Salem relies on a specific framework diagram, with a unique business service module structure, using original logic, service release inter-relationships, sequencing and business language – the opposite we find from so many ubiquitous, feature-focused technology-focused SharePoint presentations. If you want to engage with a business audience successfully, then you have to be able to explain SharePoint in plain English, quickly and in a visual way that is clear for everyone. Salem was more than that as I had determined that the Salem framework had to contain a range of common business services but also be extremely flexible to meet any unique business requirement. Therefore Salem had to be as flexible and adaptable as possible whilst still retaining the same logical structure. As importantly, the framework also had to meet the needs of software updates, new versions and even the cloud.

This was basis of the Salem™ framework that was later to develop into the Salem Practitioner certification program now made available to you today. Before this was possible I had to apply the business framework methodology in as many different types of enterprise client scenarios as possible, the bigger and more complex the better. I was able to apply the Salem framework to clients that were national and then international, spanning between 28 and 72 countries. At this stage I knew that because the Salem framework was working so well in so many different business scenarios with so many happy clients that I had the answer. Quite simply, it worked.

The next stage was to then take the Salem framework to the international SharePoint partner community and demonstrate that others could do what I had been doing successfully for so many years. Some had stated that it was my presentation style, not the framework itself – they were very wrong. Salem in the hands of others was even more powerful than before. By 2011 and in the hands of trained Practitioners in multiple countries, the results were speaking for themselves. Clients were turning their backs on other technologies and moving to SharePoint and renewing their Enterprise Licence Agreements, with CIOs citing the Salem blueprint as the roadmap they were looking for. Each Practitioner had their own original presentation style but the framework remained exactly the same, with the same modules, services logic and unique terminology.

Microsoft staff asked how we could scale the Salem framework out to the world so that we could assist as many clients as possible and reach as many people as possible and it was at this stage that we decided to develop a new, comprehensive Practitioner framework through Genius! (owned by Morgan & Wolfe) so that as many people as possible could benefit for learning to become a strategist, either independently or within the Microsoft partner ecosystem. We wanted anyone who wanted to progress their career to be able to benefit from our own learning, understanding and intellectual property as Salem is proven, tested and completely original as well as highly successful.

As the author of the Salem™ framework, I found myself at the forefront of developing the term ‘SharePoint business strategist’ in the industry because it was through my early work that I fought hard to get my audiences to understand that SharePoint is a business program far more than being a technology platform. Indeed for most of my life I have placed great emphasis on jargon-free plain-English communication. Gradually, over the last decade I have been successful in getting people to understand that the business path to SharePoint engagement is absolutely critical. For too many years, the successes of SharePoint projects have been reliant on the intermediate role of the business-language-speaking project manager and business analysts who tried to bridge the gap between IT and business stakeholders.

This gap is now filled by the formal certified Salem Practitioner, a true business strategist who is formally trained and certified in the process of both IT and business engagement for SharePoint, bringing logic, structure, sequence, rational, process and controls to any SharePoint engagement. Better still the process of becoming a Salem Practitioner for SharePoint is that it can be quick and easy to achieve through the learning structure that Genius! has put together. Salem isn’t just about Microsoft SharePoint and on-premise technology. The same logical framework can be applied to blended technology environments or even non-SharePoint environments and works as well with the cloud and Office 365 as it does with on-site implementations, a truly flexible framework approach.

Today the Certified Salem™ Practitioner(CSP) is a business strategist who may also be a project manager who has decided to step up their skills; a business analyst opening their horizons to new approaches, a solution architect wanted to hone their skills with business audiences, a developer wishing to progress their career into a more front-of-house role; an academic seeking new ways of teaching their students new business and technology approaches or a home-based self-learner looking to advance their own knowledge. Some Practitioners go on to lead client workshops and define SharePoint programs, others use the Genius! courses, masterclasses and workshops as their inspiration to look at SharePoint in a new way or indeed as a way of understanding SharePoint without ever needing to be technical.

Development companies use the Salem framework as a conceptual structure for developing new apps and original to market. CIOs find the Salem framework workshop the basis on which they can plan their future business-aligned IT strategy program and development companies use the Salem framework whilst assisting in defining future budget requirements. No longer do you need to be an IT technical guru to enter the world of enterprise collaborative systems when the logic of Salem is plain-speaking.

With the future of technology increasingly becoming cloud-driven, the role of the business strategist is becoming ever more important. Cloud services such as Microsoft Office 365 are opening up enterprise level software to companies large and small at a speed never thought possible only a few years ago. We now have Software as a Service, Infrastructure as a Service, everything is becoming an on-demand service. Technology is becoming far more commoditized, now bought off-the-shelf, driven by dynamic business requirements, where software simply does the job it is intended to do without months or years of costly development. The entire concept of Apple’s app store has had a dramatic influence on the corporate software market. But with all these services the client can end up being more confused than ever.

Today there is an increasing trend for far less emphasis (and desire) for bespoke development solutions by companies, and far more emphasis on “what do we do with all this technology – how do we put it all together”? And who is going to bring all of this together? The framework-trained Certified Salem™ Practitioner, the person who is trained and certified in the Salem strategic business consulting framework that provides the answers and standards the client is looking for.

Take a look at some of our testimonials to see how others have found great value in the Salem framework. To train as a Salem strategist you must use the official Genius! website as our training and certification program is currently available by no other route.

Copyright Morgan & Wolfe All Rights Reserved 2013

 

Eleven Ubiquitous Words & Phrases that Hold Back the SharePoint™ Industry

There are lots of words that insidiously creep into our psyche and become fashionable from time to time and when used in context or in isolation do no harm at all and may inform, enlighten and indeed enliven any appropriate conversation. All industries tend to develop their own vocabulary for a variety of reasons, from exclusivity through to a need to narrate and describe. Due to the nature of the tech industry it is no surprise that new words and phrases develop regularly, some take hold and some do not.  However, some words and phrases unwittingly hold back an industry from its own potential growth and care is therefore well advised.

The following words and phrases are ubiquitous in their use not only in the SharePoint industry itself but beyond and all in some way can be said to be hindering rather than advancing the progression of the platform and its services to a wider market. Here is my rationale for some of the more obvious ones:

1. Intranet

What does the word ‘intranet’ say to you? Now what does it really say to you? For many business users ‘intranet’ speaks of a confused, out of date, badly constructed, impossible to navigate, out of touch, irrelevant, arcane, archaic, legacy investment which today cannot be trusted as authoritative. Therefore when you come to introduce a new intranet on SharePoint, for many, you are simply using the latest technology to replace something unpopular and repeat the problems of yesteryear. Intranet is not an obligatory term and neither does it adequately describe the power of SharePoint, so why use it at all?

2. T&M

T&M, more accurately termed Time and Materials describe the all-too-common approach by solution integrators to costing SharePoint solutions. More importantly T&M describes the frequent unwillingness by Partners to commit to a fixed price for a solution based primarily on the one-way argument that the client may change their mind and scope may vary. Worse is the argument that detailed requirements are unknown and therefore a fixed price is not plausible.

If one applied the same rationale to SAP or similar, one would be writing a blank cheque that could end up costing tens of millions of dollars and it comes as no surprise in the current global economic climate that client organisations are increasingly wary and weary of the constant surprise regarding SharePoint costs. After a decade of SharePoint installations and solution development, a large proportion of the more common solutions are well known in terms of cost and T&M is far less appropriate than ten years ago in many cases.

The future of packaged applications and cloud, SaaS services may well see the demise of wholesale use of the T&M model. If we cannot be clear to a global client market what things cost, or that services are expensive and not easy to budget for then be assured that engagements may be limited or difficult to attract.

3. Point solution

Point solutions have supported a global SharePoint industry for years. A point solution is a solution developed in isolation for a specific requirement and not linked to any other relational service. More commonly put, ‘tell us what you want and we will build it’. In part this occurred through a common misconception that SharePoint is best sold as a development platform. In turn single solutions required single disconnected projects and most corporate IT departments are based on a project-centric model.

Single projects largely fail to employ an economy of scale, budget or resource and are packaged as single entities that live for their own selfish reasons. Multiple disconnected projects on the same platform using one or (worse still) multiple vendors on the same platform quickly start to trip each other up and place a budget burden not on a business stakeholder group but on multiple single project sponsors.

It is the failure to take a business program approach to the platform that has meant that SharePoint to date has squandered an intrinsically valuable opportunity to establish itself at the heart of organisations for a wide range of interconnected enterprise services that themselves are mapped out using a business roadmap and blueprint like Salem™.

Ultimately the project centric approach has left SharePoint as being seen as unnecessarily  expensive, slow to develop, release and adopt and cumbersome. Far too many SharePoint implementations have run out of steam due to a lack of long term program budget planning, resource and role planning and business program alignment.

4. Developer

Let’s make it clear, I believe that SharePoint’s versatility is an extremely strong value proposition and the ability to develop an eternal number of business solutions makes SharePoint extremely valuable to every organisation. Consequently I am not against ‘development’ in any way, when warranted. The term ‘developer’ however has increasingly become equated to unmanageable expense, slow delivery, and bespoke services that are difficult to maintain, particularly with version upgrades.

Microsoft has demonstrated the issue clearly with its new SharePoint 2013 model where code does not interfere with the kernel and remains separate thus un-hindering clients from future core SharePoint platform upgrades.

For far too long the recruitment industry, together with portions of the SharePoint industry have been guilty of perpetuating the myth that if you are implementing SharePoint you must begin by employing a team of developers. Therefore from the very outset clients have taken a view that it is impossible to make any headway with SharePoint without developing using skilled developers.

You can imagine their surprise therefore when client organisations have later discovered out-of-the box services they had not been shown previously and therefore realised that there were many less costly opportunities to make early headway. Therefore whilst there is absolutely nothing wrong with the role of the SharePoint developer it has largely been the misuse of the role of the developer in the overall SharePoint strategic program that has upset many clients and made them wary of further development investment. 

5. Extranet

Similar to Intranet but leading to even more confusion, 'extranet' is largely a technology term that has little obvious business meaning behind it as it is not one of common parlance. Essentially people in an organisation wish to collaborate and share with people outside the organisation identified by name, that’s not so hard to explain and is common in terms of requirement. The word extranet is symbolic more than anything else of the major problem still facing organisations. 

In many respects the word 'extranet' represents the larger techno-centric argument that nothing can be explained in plain English when it can instead have a term that no one finds easy to comprehend. It is as if technology is buried deep in the psyche of science fiction where abstraction is a necessity and deliberate through choice to the exclusion of the masses.

6. Social

'Social' is the word du jour and a word that is increasingly being over-used and misinterpreted as well as being incorporated into phraseology such as the even more diverse ‘enterprise social’, ‘social enterprise’ or even ‘social collaboration’. Let’s make a bold statement here, in the context of business there is nothing truly social about social technology in the workplace, but instead and far more importantly what social really means is ‘applied social networking techniques’. This means that rather than using software to announce how much beer you drank last night, you are using the services found in the common social network platforms reassigned for business subjects. Gartner backs up the issue by demonstrating that only 10% of 'social collaboration' scenarios achieve a degree of success.

Be in no doubt that many business directors request that social tools are switched off, that they distract workers from daily tasks and offer difficult governance for overstretched HR departments. This is no different to the slow embrace of instant messaging a decade or more ago. 'Social' for them is something that happens after work, not during work hours. Therefore the tech industry needs to decide and agree what ‘social’ actually means in the context of business and work. Rather than scaring organisations, use appropriate terminology that attracts and enhances an organisation instead of presenting technology that may not be, in many instances, interpreted as business appropriate.

 7. Partner

The word ‘partner’ is extremely common in the Microsoft ecosystem and something that is passed through to the end customer. Partnering is of course a very worthy objective and one that many aspire too.  Partnering with anyone is of course very difficult to achieve well whether with an individual or indeed a large corporation and therefore grand statements such as ‘our mission statement is to partner 110% with all our clients’ is largely meaningless. Most ‘partners’ are in fact effective deliverers of SharePoint solutions for which they get paid specifically for their time and effort and which is indeed exactly what most clients want.

Partnering takes the deliverer to an entirely different level of business relationship which requires sharing, including the sharing of risk, closeness and embrace of distinct corporate cultures which in practice most solution delivery companies find very difficult or costly to achieve. Therefore the word ‘partner’ comes to mean something akin to over-promising in a way that undermines the value proposition of the intrinsic relationship itself.

Due to the fact that many clients have failed to find true partnership from their solution integrators then it may be far more appropriate to make the statement that one is an expert SharePoint solution integrator than an expert SharePoint partner and not define a relationship that will never really materialise.

 8. Governance

Probably the most misused and much-maligned term in the SharePoint industry and one that continues to cause debate to rage to this day. Do you mean technical governance, business governance, administrative governance, product governance, what? Governance simply means the ‘act of governing’ and in which case the act of governing of SharePoint is performed by its stakeholders and business sponsor, beyond this there are many other ‘acts of governing’ required to be performed in various ways and to various degrees by various parties en route to SharePoint success.

However because the SharePoint industry continues to squabble as to what governance means and which software company owns the ‘right’ to the term governance, so the client audience is left cold, detached and disinterested. For many client organisations governance sounds like a complex turn off that in turn ensures that SharePoint itself appears difficult to embrace.

 9. SharePoint

This is probably the most difficult word of them all and one that causes the most issues. We have had SharePoint Portal Services, Microsoft Office SharePoint Server, Windows SharePoint Services, SharePoint Foundation Services, SharePoint Online and finally SharePoint, phew!  So they finally agreed on the word SharePoint as a brand identity and just when it was safe to come out and face the music in point 11 its not SharePoint anymore, now its the cloud and Office 365. Are you thinking what I am thinking?!

The issue isn’t with the word 'SharePoint' as a brand name, though its  recent agreed naming convention does make things easier to progress its identity in the long term (see point 11 though). No the issue is with how one describes SharePoint, what is it? You can describe Excel as a spreadsheet you can describe PowerPoint as a presentation-maker and you could describe Word as a word processor to keep things simple. If you can’t describe something to your mother in 60 seconds what hope do we really have?

The issue with the word SharePoint is that it does not have a single identity and indeed has so many identities that it suffers from a form of extreme schizophrenia where it can be one thing to one person and something completely different to another. Yet at its core, SharePoint contains a set of common features and services that every organization can and should benefit from.

It is due to the fact that over  decade later, whilst the global SharePoint industry still refuses to agree on a simple way to describe its platform that it struggles to demonstrate real business value with ease and why other platforms and services continue to make ground. There may come a tipping point where, however great SharePoint is, client organisations simply start to move in a different direction.

 10. Requirements Gathering

‘Requirements gathering’ is a phrase that sends the fear of God into the heart of many potential clients and yet one used by the majority of solution integrators, it is a phrase that sets out a process of finding out in detail what the client wants incorporated into a specific solution. The problem is that many organisations simply aren’t sure what they want, or of the detail that must be defined within a solution.

The thought that clients need to undergo weeks of relatively expensive, business-impacting requirements-gathering workshops is off-putting to the extent that many organisations are now actively seeking shrink-wrapped solutions (latterly known as Apps) that take away the arduous process of discussing in fine detail the opinions and requirements that will lead to a final cost proposal. Ask a client if they will forego an exact service match for one that is fast to deliver, requires no requirements-gathering but only meets 70% of understood criteria and many will absolutely say yes please.

The world is quickly moving on and the inference that anything built on SharePoint requires a long-winded requirements-gathering process that can be costly, time-consuming, politically troublesome and difficult to finalise can lead to early disaffection by stakeholders that they then refuse to repeat. Many organisations have stated that their technology partners should provide clear thought-leadership by demonstrating what many other organisations have already achieved thus removing the requirements gathering hurdle.

 11. Office 365 (or 'Cloud')

An odd choice you might think and a topic that is currently flavour of the year, the SharePoint transition to the cloud. The problem is that the brand name Office 365 dilutes SharePoint, hides its presence and appears to suggest SharePoint is something far less than it really is, something slightly inconsequential, light and ad hoc. There is an inference that SharePoint Online requires far less thought, due diligence, structure, strategy and planning to adopt now that it is ready made but indeed the requirement for business aligned strategy for SharePoint does not change whether it be onsite or online. Office 365 does not take away much of the strategic requirements found with on premise SharePoint implementations. 

More worryingly still is the idea that this dilution of SharePoint may be deliberate to move by those who have never grasped what it actually is and have had no strategy for it. There have indeed been suggestions in some articles that Office 365 heralds the end of SharePoint and its parts will become independent services in the cloud.

Could you imagine SAP as being part of an Office suite or any other enterprise product for that matter? No, neither can I. As SharePoint is an extensive and powerful enterprise platform, placing it within a package offering and taking away its primary name thus taking away its independent identity is itself something that may stifle its long term growth. Add Yammer into the mix in Office 365 and one can see how the cloud branding can cause real issues for an increasingly bewildered corporate consumer market.

These are only some of the many words I could have chosen for this article but the tech industry continues to define itself largely by being distant and distinct from the businesses it services through its fashionable and all too often abstract use of vocabulary. In the time we now live in, the ability to be succinct, clear, and drive real business value quickly is a high priority for many organisations and it is for this reason that the words and phrases that the SharePoint industry chooses to engage with and define itself by, may well define whether it remains in the dictionary a decade from now.

Best Laid Plans: Ten Reasons for the Requirement for a Client-Side SharePoint™ Project Manager

It is fascinating how many SharePoint™ clients adopting SharePoint fail to consider employing a dedicated SharePoint-literate Project Manager in a timely and appropriate manner. Given the fact that the Salem™ series of SharePoint™ strategy articles advocates a professional programmatic approach to a highly-involved platform, it is therefore natural that we turn our attention to the subject of the SharePoint project manager, or more specifically, the lack of one.

I cannot count the number of clients who, in engaging with SharePoint have failed to see the need for a project manager with any skills in the platform which underlines the common problem that client organisations see SharePoint as just another software platform that can be controlled and managed through to service delivery by anyone who can create a timeline, write a risk report and issue log, yet with no appreciation of what they are about to encounter nor embrace.

Let us therefore consider, in a pragmatic way, ten random but poignant reasons why every client without question should consider the requirement for a client-side, appropriately experienced and trained SharePoint Project Manager.

Here we go then:

1. Delivering SharePoint is a full time, skilled job

SharePoint™ requires a portfolio of skills that may not be found with a traditional project manager. I have worked in many environments where the traditional PM sits 8 hours a day staring at a risk log and Gantt chart and communicates with the stakeholders mostly by phone and email. With SharePoint the PM is actually performing a wide range of roles simultaneously, frequently at the coal face, performing everything from presenting the benefits of the platform itself, to presenting and leading stakeholder meetings, to acting as pseudo business liaison officer, to working with the service delivery partner all the way through to training administrators and other personnel.

There are so many strands to successful SharePoint service delivery on the client-side that employing someone who is unable to plan and anticipate what SharePoint will require to occur is a highly risky business prone to failure.

By employing someone who already knows that these tasks will be, how they work best, how to engage both the business and technology and anticipate risk, the better time will be used and the more likely you will be to progress.  For clients, ignore this advice and investment at your peril.

 2. SharePoint requires a central, experienced liaison point

Delivery of SharePoint services requires liaison between a wide range of personnel both within the client and with suppliers, contractors and service delivery partners. Think of it like spinning 50 plates at once and these plates start spinning very quickly with the PM standing at the centre. Keeping everyone inter-connected and communicated with regarding what needs to happen and when only comes with experience in the SharePoint field, therefore platform literacy is needed to ensure that everyone is asked the right questions and provides the right questions at exactly the right time. A generalist PM will probably not know which questions will need to be asked, why, when and what the follow-on actions will be.

Central liaison on a SharePoint project requires immediate understanding of what is happening and why and is something that, if learned as one proceeds, will slow the entire project down and start to increase costs and timeline impact. One cannot underestimate the amount of liaison required with business stakeholders and how it can stretch both available time and resources.

 3. SharePoint is the sum of series of interconnected projects

Inevitably and so frequently wrongly a business service will be deployed using SharePoint without any thought or consideration to any further service that ends up using the same platform. Consequently design and service decisions are sadly made in isolation, driven by stakeholders who have a somewhat understandable myopic view of things and aren’t typically interested in other projects but primarily their own.

Whilst many clients are notorious for avoiding ‘program manager’ roles in favour of the rather more mysterious (i.e. non-existent) and somewhat cheaper ‘Senior SharePoint Manager’ role, many SharePoint Project Managers are indeed fulfilling the vastly more complex role of the SharePoint Program Manager. That is in itself a good reason for selecting a SharePoint-literate project manager.

What the SharePoint Project Manager does is knowledgably anticipate business decisions and advise accordingly to ensure that some decisions do not occur in isolation when they will clearly affect parallel and subsequent projects using the same platform. It is the anticipation of the inter-connectedness of SharePoint services that is critical and something that the SharePoint PM suitably provides.

Whilst you may rightly argue that design decisions should be led by solution architects, the architect sessions are frequently usurped by ad hoc and sporadic decisions by business and IT stakeholders when the partner architect is not present, therefore it is down to the client-side project manager to fill the gap, temporarily.

 4. SharePoint uses a specific vocabulary

Whether it be content types or site collections or content databases or web parts there is an intrinsic language to the scripture of SharePoint that is not learned and understood overnight. Working with a partner organisation any client will be expected to understand the language and therefore the SharePoint Project Manager acts as the skilled translator or interpreter who can translate what may be complex technical queries into suitable business language appropriate to the audience in hand. The SharePoint Project Manager can speed up the entire process by working with the business stakeholders separately and educate and prepare them with the language until everyone is speaking the same language. Failure to address this role will present friction amongst a number of parties caused back failure of communication.

 5. A partner requires a SharePoint literate liaison point

Further to the above, the SharePoint partner, if there is one, will be asking very specific questions of the Project Manager which the PM will be expected to understand and action. The more a partner has to spend time supporting the client project manager the slower things will progress and the more likely there will be friction, issues and mistakes if the client PM is not clear what is being asked of them.

The SharePoint Project Manager will be working in unison with the partner project manager, solution architects and lead developers amongst others and may need to liaise with other related partners for workflow, packaged applications and other services. The sheer weight of current market knowledge and partner experience will ensure that the SharePoint Project Manager is able to drive the project or program forwards whilst keeping control of both the budget and the partner activities like the conductor of an orchestra. Would you employ a conductor that had never heard the piece of music before?

 6. Failure to anticipate will cost time and money

As a SharePoint Project Manager is an extremely knowledgeable resource, so they will be able to advise where and when things should occur and when money will need to be spent and where it can be saved. Here is a simple example. In deploying a SharePoint solution there may be a requirement for cross-training the incumbent second level support team. This may not have been anticipated in terms of cost and budget but by understanding the potential requirement, the SharePoint Project Manager could suggest that the incumbent team is trained to deploy the solution iterations as part of the testing phase which in itself acts as a cross-skilling exercise.

There are a thousand examples just like this. The more the SharePoint Project Manager brings to the table, the safer the client program/project will be.

 7. SharePoint PM skills establish a standard base line for the future

In a SharePoint service implementation the SharePoint Project Manager is able to lead by example, to demonstrate how things should be done, by putting into place the project assets and collateral that can be reused time and time again. Assuming that SharePoint is not being deployed for a single business service and that many others will follow, so the skilled Project Manager will be adapting current processes and existing project templates and documentation to suitably fit the subject of SharePoint for future projects and as such will establish a performance and process base line. This will occur as a natural part of the initial service delivery process. It would be almost impossible to achieve this using someone not already literate and experienced in SharePoint projects.

8. SharePoint Project Managers can see all sides of the service equation 

Whether you wish to call it empathy, pathos, understanding or comprehension the SharePoint Project Manager is able to work with everyone from the infrastructure architects through to senior business management and take on board all aspects of the equation and fit them together to ensure that SharePoint is delivered fit for purpose.

Whilst some of this occurs via the solution architect role, the SharePoint Project Manager is partly fulfilling a role of a SharePoint Business Strategist (hopefully Salem™ certified) and taking no sides but working out how to fit the greater parts of the strategic jigsaw together and then advising accordingly. In other words the SharePoint Project Manager knows how to handle the complexities of the SharePoint project in an objective fashion but to fight the corner of those who are under-represented.

Into this area one can also pull the complex area of SharePoint governance where diplomacy and skill is required to put together the governance structures and groups who will drive the policies that underpin the SharePoint program and projects.

 9. The SharePoint Project Manager is Switzerland (i.e. politically neutral)

There is a great deal of benefit to be said for bringing in an independent SharePoint Project Manager from outside the organisation (but not from the delivery partner) for the establishment of the SharePoint business service program and duration of the first SharePoint project delivery phase. This suggestion is primarily to gain an independent view of the entire status quo, to ensure readiness and preparation on behalf of the client and to allow the PM  to say and do things that are independent, unencumbered, uncomfortable, unpopular or indeed impossible for an incumbent member of staff.

A SharePoint Project Manager role is not an easy one and straddles a number of political camps regarding ownership, business versus technology and others. I have encountered a large SharePoint program where two directors competed continuously with one wishing the other to fail. By being independent there is a greater chance of success because the SharePoint Project Manager can drive through change and (hopefully) remain above the day to day politics inherent in any organisation.

10. The SharePoint Project Manager is really a Program Manager and SME 

The chances of a SharePoint Project Manager hiding behind an MS Project Gantt chart and weekly status report are none existent. From the word go SharePoint is an all-encompassing, all day, full-time activity that requires everything from ingenuity to strategic skills to pull off successfully. For most other ‘players’ on the SharePoint chessboard, they have very specific roles to play but the Project Manager is asked to wear many hats, fill many shoes and sit in many chess squares, all at a moment’s notice and be a friend, confidant and educator to everyone else. It is for this reason alone that those who have successfully delivered a number of major SharePoint projects have developed a skill range that is often exceptional, though all too often underappreciated and undervalued. 

Due to the wide ranging insight and knowledge that SharePoint Project Managers bring to the table, they are often seen as on-site subject matter experts handling far more than an individual project and very often the entire service program. It is no wonder therefore that to seek substantiation in their position, SharePoint Project Managers are now seeking further substantiation of their experience and skills through tracks such as the Certified Salem™ Practitioner. 

Conclusion

I am sure you can add to this list but these are ones that stand out for me. All Project Managers, whether SharePoint literate or not, aim to deliver solutions to time and to budget as well as to client satisfaction. When one project finishes another may commence or a number of projects may run side by side. Most Project Managers are certified in one or more project management methodologies which assist in establishing process and control and can be adapted for any particular organisation's internal processes. These things should be an absolute given.

The purpose of this article is to demonstrate that there are very specific reasons why SharePoint Project Managers are specialists who have a very particular, beneficial role to play and are very valuable to the success of any client SharePoint™ engagement. There will always be those who believe they know better on the client side and select someone from their own internal team who is requested to learn on the job. This decision often marks the difference between those clients who succeed with SharePoint™ and those who fall by the wayside. For me the SharePoint Project Manager is all too frequently the unsung, heroic lynchpin of the SharePoint client service industry.



Copyright Genius! by Morgan & Wolfe. All Rights Reserved 2013.