Nintex Workflow Complexity

Some of the feedback I have received after my recent post Why would I buy Nintex? was in regards to how to gauge the complexity of your workflow.  Now one way is to actually map out the process and see how much work there is in automating the process.  The problem with mapping out the process is that now you have gone a long way down the road and are not even sure it is viable to re-engineer; although I recommend it even if you were not doing workflow automation.  The other way, which I want to go through today is a simple way to quickly evaluate it so you know whether it is a simple, medium or complex workflow.


The other question that users often have is, How do I know if there is value in automating a process?  I will go through each of these and hopefully provide you some insight that makes your life easier or at the least clarify something you had a question about.

Part I - Gauging Complexity

Now. like my previous post I am going to do some basic math that you can apply to calculate the level of complexity, first I want to define those levels and then you will know a ball park of the budget to map and create the workflow in question.


Before I get into defining the levels of complexity, I want to point out that the majority of effort in process automation is the actual mapping and redesign, not the programming, though the programming is the direct cost, while the other efforts are not. 


As I mentioned above, process mapping should be an existing function within your business units, it allows you to see your processes and quickly identify areas for improvement, if it is not being done regularly, you may have a lot of work ahead of you.  The good news is you can and should take an iterative approach to making this happen.  What I mean by that is that you can record it and come back to it as needed to refine the process; processes are often moving targets until they are mapped and set as a standard.  There is really only one rule you can rely on with an undocumented process and that is the process will change!, so map it as soon as you can, communicate it to everyone and make modifications as necessary.


A simple rule to use for gauging the amount of time to map and reengineer a process is typically 60-80% of the total time to get a final automated workflow that meets your needs.


Ok, so let's talk about complexity, as I mentioned above we can use some simple buckets (if you will) for the complexity of the process automation. A simple workflow is from 0-40 hours of effort to create, a medium complexity workflow takes from 41-120 hours of effort to create and a complex workflow takes more than 121 hours to create.  These numbers are based off the use of Nintex and you can multiply then by 2-3 times for C# development, depending on how good your developer is.

Complexity of the Workflow

Ok, so now that we have an idea on the size of the buckets, we can do our math that will help gauge which bucket our proposed workflow should fit in.  If we look at a process from a high level we can ask and answer a few questions that will help us gauge the complexity.  I will explain why it is important before we calculate.

1. How many users in the organization does this workflow affect (meaning how many are going to use it)? N
2. How many people/business units are going to need to interact with this process? I
3. Roughly how many steps from beginning to end do you perceive? S
4. How many possible results are possible (roughly)? R
5. How many different systems are involved? V

Ok, so we have some variables and here is why they are important.

1. N is a number that represents the number of employees (in multiples of 5000) utilizing the workflow, the larger the number the more impact on complexity, a good rule of thumb is that you can expect the workflow complexity to double for every 5000 users that interact with it, but anything less than 5000 should not affect it.
2. I is the number of interactions, for each person/ business unit that interacts with the workflow you can expect roughly 5 additional actions in the workflow.
3. S are the total number of perceived steps, for each of these steps you can expect roughly 5 actions in the workflow.
4. R is the number of results, in a workflow these are different paths and it is easiest to think of it as a multiplier of the number of tasks where two or one is the base number of outcomes and the addition of another result will effectively double the actions.
5. V is another complexity multiplier, when ever we interact with any system outside SharePoint, we are doubling the complexity.

So here is what the formula looks like:

1. N = Answer to Q1/5000, Round up
2. I = Answer to Q2 * 5
3. S = Answer to Q3 * 5
4. R = If Answer to Q4 is 1 or 2, then 1 otherwise Answer to Q4 - 1
5. V = Answer to Q5 (there is always at least SharePoint)

X = (I+S)NRV


Now if we use an example of a company of 250 people wanting to do a vacation leave workflow.  The workflow needs approval from their direct Manager and notification sent to the requestor and HR of the result.  The vacation leave needs to poll the Accounting system to determine the number of days available for leave and then deduct the amount when approved.  From this scenario we can calculate the complexity as:


Q1. There are 250 People
Q2. There are 3 interactions (Requestor, Manager and HR)
Q3. There are 6 steps

1. Make the request
2. Poll the accounting system
3. Send to the Manager
4. Deduct the Leave
5. Notify HR
6. Notify the Requestor

Q4. There are 2 results.
Q5. There are 2 systems (SharePoint and Accounting)


I = 3*5 = 15
S = 6*5 = 30
N = 250/5000 = 0.05, Rounded up = 1
R = 1
V = 2


X = (15+30)*1*1*2 = 90


90 is rough hours to create your workflow using Nintex. If we put that in our bucket we would say this is a medium complexity workflow, which I would expect due to the interaction with the accounting system.  I personally would use the upper end of the bucket for medium and low complexity workflows and would perform a proper mapping for anything that seems to be complex.  Be prepared however for changes in interaction and re-evaluate any workflow each time there is a change in scope as it affect complexity, especially when dealing with the multipliers.

Part II - Gauging Value

The second part of this is how do I gauge the value of automating a workflow?  You can do time and motion studies and determine the actual time spent on tasks, or you can use rough numbers again.  when using the rough numbers in this case be optimistic on how quickly people are performing the process today, it will give you a pessimistic value for automation.


In part one we asked the question, how many users interact with the process, this number will be used again as a base multiplier.  We will then ask two new questions,

1. How much time does someone currently spend doing this task? remember be optimistic, ask a small sample and take the lowest three numbers averaged as your result.
2. How often do they need to do this task? again ask a small sample and take the three largest occurrence averaged out and represented as a yearly amount.

Now we simply calculate:


N = Number of people
T = Time spent currently (in Hours)
O = Task Occurrences/Year


X = NTO


The result is the number of Man/hours/year spent on this process.  You can then compare that to the estimated savings in time spend and the cost of development, here is a continuation of our above example.


As above, when asked the above questions we get the following answers: currently our people spend an average of a half hour filling out and submitting a leave request, then carrying it around for approvals and checking the system for available leave.  Based on the small sample people do this once a year.


So now let's do the math:


X = 250*0.5*1 = 125


So currently it costs the company 125 man hours for leave requests, we can expect the workflow to reduce the time of a leave request to roughly 15 minutes (note I am being pessimistic the other way now, taking the maximum time it should take).  If I calculate this I can then get a gauge on how long it will take before I make my money back.


X = 250*0.25*1 = 75


So we can expect to half the total number of man hours by automating this workflow, but the 90 hours we incurred above to develop it, means we will not positively affect the bottom line until the second year (90/75 = 1.2 years ROI).  Is that worth it, I guess it depends on you...


Feel free to follow me on twitter @DavidRMcMillan or @DevFactoPortals or become a member of this blog.  Thanks, feedback is appreciated and encouraged!

Why would I buy Nintex?

In my blog post ECM Governance - Post 5, I mentioned that I should post about Nintex and how to determine an ROI for the purchase; I bet anyone who knows me never thought I would get a post out this soon...

So, first things first, lets talk about Nintex. 

First, I want to point out that I do lead a large SharePoint practice in Western Canada and we are a Nintex Platinum partner, but that said, I am not driven by sales here, I am driven by a piece of software that can make your life and SharePoint solution better.

Nintex is a company, not a product, in reality Nintex offers several products, but when SharePoint people (like me) talk about "Nintex" they are referring to two products (Workflow and Forms) that are often bundled together as a BPM solution for SharePoint.  These are the products I am going to examine and hopefully explain how you can gain value and save money in their use.

What does Nintex do that SharePoint doesn't?

First Workflow...

Now this is a question I get a lot, while the answer was simple, it has recently changed.  I used to say that Nintex doesn't do anything you can't already do with SharePoint, but now I have to say it doesn't do a lot more, but it has some additional functionality when it comes to integration.  So now you are saying, if it doesn't add much, why would I buy it?  Well that answer is simple, while SharePoint offers extensive workflow capabilities out of the box, you need to be a developer or employ a developer to leverage it.  Out of the Box (OOTB) SharePoint needs either SharePoint Designer or Visual Studio to create anything but the basic workflows in the platform, while the workflow development tools are there, unless you know C# I don't see you creating workflows anytime soon.

Nintex changes all that, it takes what is a programming interface in SharePoint and makes it a graphical interface, then it adds in all the parts that take a lot of effort to program, like auditing, tracking and performance monitoring and throws them in.  The first advantage this gives is that it allows developers to mentor power users in the creation and maintenance of their own workflows (though this still takes a lot of time and effort because it still follows programming logic).  It also allows your developers to reduce the time to create a workflows by a factor of three (from my experience) and finally, everyone can see the workflow and each step as it executes, tracking the time for each step, the decisions made and auditing each step in real time.

Then Forms...

Until recently I would answer that forms provide a nicer interface than the Microsoft tools (InfoPath)and an easier way to brand your forms consistently, but since Microsoft announced the deprecation of InfoPath, Nintex Forms no longer has a Microsoft equivalent to compare, making it and other third party tools a requirement if you want to customize the form user experience.

Ok, so how can we calculate an ROI?

Now I am going to simplify the math I am using, I will first go through my basic Math assumptions and rough estimates (over estimated) cost for Nintex (Forms and Workflow), then you can see where the break even should be.

Assumptions

• Nintex Cost $15000 USD per Web Front End (WFE) = C
• You have two WFE Servers (for load balancing and redundancy) = S
• The average C# workflow will cost $10000 (from my experience it is usually more) to develop = W
• Nintex Reduces your development by a factor of 2 (as mentioned above, my development team has typically realized a factor of 3) = f
• We will not account for the value added by Forms or by Power Users who learn to develop workflows.

The Formula

Where X = Number of Workflows to Breakeven

XW = CS + (XW/f)
10000X = 30000 + 5000X
5000X = 30000
X = 6

The teacher always said, Show your work, lol.  Now realize by over estimating the cost Nintex, underestimating the cost of a C# workflow and under estimating the factor of improvement, we achieve a worst case scenario or 6 business processes before you begin saving money, the reality is most of my clients realize it between three and four workflows created.  I guess the question to you is, how many workflows do you have that could be automated and is there any advantage to them being automated?

If you want to find out more about Nintex, you can go to their website:  http://en-us.nintex.com/

If you want to follow me on twitter I am @DavidRMcMillan or @DevFactoPortals, feedback is always appreciated, good, bad or indifferent. 

ECM Governance - Post 5

I think it is official, I suck at blogs, but I promise to try to post more (not saying I will), but one thing you can be sure of is a tweet when I do.  I seem to be getting worse at this, rather than better, blog posts always end up being low on my priority list and the time between seems to increase, not decrease.  Today I wanted to finish off the definitions of the different principles and then we can move on from there, hopefully in a more timely manner.

Collaboration Principles

Collaboration principles are principles that describe the way in which we plan on using the Team, Project and other collaboration site capabilities of the solution. It should include things like the site design, which lists and libraries are standard, the security roles used in collaboration, Content Types for templates and anything else you want to control in the collaboration portion of your solution.

Collaboration principles are about the control of who can do what, where and when. They provide a foundation for collaborative interaction and as such are always used in your solution in some way. As an example of a Collaboration principle, I have included "Collaboration sites will inherit the top menu navigation from the parent site", which encompasses the fact that collaboration sites are more loosely controlled than portal sites and control revolves more around the user experience.  Later when we examine the application of policies, we will see that as we move down the hierarchy from portals to collaboration sites and then to my sites, we change from highly structured and restrictive control to a looser user enabled control, but more about that later.

Collaboration sites will inherit the top menu navigation from the parent site
Principle
Collaboration sites will inherit the top menu navigation from the parent site.

Implication
To maintain a consistent user experience, the same top menu is used throughout all collaboration sites, Site Administrators will have no control over navigation.

Business Process Principles

Business Process Management is a core function that every ECM needs and SharePoint is no exception.  The one caveat I have to say is that SharePoint sucks for creating workflows and forms, thank goodness they deprecated InfoPath, Nintex does a far better job in the forms area and makes it possible for power users (with training and mentorship) to create some complex workflows.  The developer will never disappear for the complex workflows, but his work is minimized, providing a better return for the organization.  Come to think of it, the ROI of a tool like Nintex seems like a good topic for another blog post, stay tuned for that too, lol.

Anyway, regardless of the tools used, BPM needs some structure around how workflows, integrations and forms are created, where they are stored, how they are executed and anything else you think will need a boundary around.  In this example I have created a principle for the management of alerts and notifications, which fall under business process management.  The principle is intended to reduce the overhead of managing alerts and notifications, but ensuring users are responsible for managing their own alerts and notifications.  Coupled with this principle are other principles around training for users and principles for notification and alert creation.

Each user is responsible for the management of alerts and e-mail notifications
Principle
Each user is responsible for the management of their own alerts and e-mail notifications.
Implication
While anyone can assign alerts to others, each user is responsible for the maintenance of their own alerts and notifications. Each user needs to ensure they receive the notifications they need.

Esthetic/Site Design Principles

Now I changed the name of this, many ECM governance practitioners will call this user experience, but for me, it is more than just the user experience and encompasses the brand, navigation, search style guides, master pages, XSL transformations and anything else that affects the look and feel of the solution, including site and page templates.  These rules are often the most important because they directly affect the user experience and adoption; no one like an ugly site. 

I remember a developer that once worked for me, he had recently come from China and I asked him if he could brand our product SharePoint site.  He said "yes" and with a slight head bow, immediately set to work.  He ended up spending the evening at home working on it, so when I came in the next morning, he proudly presented me with a SharePoint team site branded in bright red and gold, or as his cohorts called it the ketchup and mustard brand, very much like the 1980's McDonald's I grew up loving... but alas there was no Hamburglar anywhere on the site.

That little story illustrates why this is so important, every user has a different idea when it comes to look and feel and if I had simple used a governance principle that said his brand had to align with the corporate style guide, there would never have been an issue; well maybe.  I have included a couple examples in this case, one that identifies the importance of user experience, the other ensures no one thinks they can make up their own brand.

Prefer Findability over Authoring Convenience
Principle
Ensure that “findability” governs design decisions – optimize metadata and site configuration to provide the best value for the end-users, not just the content contributor.
Implication
In situations where design trade-offs must be considered (more metadata versus less, information above or below “the fold”, duplicating links in multiple places), decisions should be made to make it easier for end users rather than content contributors. “Findability” means designing sites so that important information is easily visible and that navigational cues are used to help users easily find key information. It also means using metadata to improve accuracy of search results. Both the “browse” and “search” experience for users will guide design decisions in initial site development and modification over time.

All publishing and collaboration sites will be consistently branded
Principle
All publishing and collaboration sites will be consistently branded.
Implication
In order to maintain consistency in the look and feel of the intranet, standardized brands will be used for collaborative and publishing sites and will not be modifiable by the site owners.

Content Principles

Where the Esthetic principles are the most important principles for user experience and adoption, content principles are about making the solution fit for purpose, after all this is an ECM we are taking about (emphasis on the "C"). In reality, my experience has proven that the content principles will out number all the other principles combined, why, we can every content type will need principles to define it. Whether we are talking about a metadata field, a vocabulary, taxonomy, document, list, image, template page or alert, it is all content and that means that principles that affect any part of the system will probably affect the content principles.

Because content principles are such a vast area, I have included several examples to help you get started, but understand even in the beginning this category is the main part of a governance document. Some of these you have already seen, which reinforces my point of overlap, yet I am sure you can see how they apply to more than one category.

All content is owned
Principle
All content must have a clearly identified “owner”.
Implication
Users need to know who to contact if content on a site is out-of-date or inaccurate. The content owner is accountable for all the content in a site and for ensuring it is up-to-date. Each site should have a clearly defined owner that is visible on the main page of each site.

Maintain a single source of truth
Principle
All content exists in only one location.
Implication
This means that the official version of a document is posted once by the content owner. For the reader’s convenience, users may create a link to the official copy of a document from any site, but should not post a “convenience copy”. Users should not post copies of documents to their personal hard drives or My Site web sites if they are already on a site.

In situations where some documents or records need to be available offline due to a very slow or inconsistent connection to the SharePoint sites, SharePoint Workspace can be used to make these records available offline.

Use built-in versioning
Principle
Edit documents in place. Do not download or make copies for editing, if possible.
Implication
Version control will be enabled in document libraries where prior versions need to be retained during document creation or editing. If prior versions need to be retained permanently for legal purposes, “old” versions of documents should be stored as records. Documents should be edited in place rather than deleted and added again, so that document links created by other users will not break.

Sponsors/Owners are Accountable
Principle
Site Sponsors/Owners are accountable, but everyone owns the responsibility for content management.
Implication
All content that is posted to a site and shared by more than a small team will be governed by a content management process that ensures content is accurate, relevant, and current. Site Sponsors/Owners are responsible and accountable for content quality and currency and archiving old content on a timely basis but site users are responsible for making Site Sponsors/Owners aware of content that needs updating.

Business Intelligence Principles

Business Intelligence principles encompass the use and presentation of BI data, reports, dashboards,  charts, graphs and KPIs.  They are intended as with any other principle to provide both consistency and ease of management, with the later being very important.

In this example, we define a principle that ensures we are controlling access to the BI tools, which require an enterprise license in SharePoint.

The Business Intelligence Centre can only be accessed by the BI User role
Principle
Only the BI User Role will have access to the BI Centre
Implication
To control the Enterprise license in SharePoint the BI Centre exists in it's own web application and can only be accessed by users who have the proper licensing.  The BI User role has been configured to ensure compliance with the Microsoft licensing model.

So anyway, this one took a long time, so I made up for it with more content, but I am trying to get my MVP, so I may need to blog a lot more, it doesn't do a lot of good knowing a bunch of stuff if I am not going to share it with the world.  Got to change the IT world, one client or reader at a time.

ps.  follow me on twitter, @DavidRMcMillan, I will post articles and where I will be speaking there.

ECM Governance - Post 4

Guiding Principles continued

Hi Everyone,

Last post I had a pretty short entry and it took a long time for me to get it out, unfortunately work sometimes gets in the way of my sharing of information as you can see I haven't posted in some time due to client constraints, anyway, this post I want to continue the descriptions of the different categories of guiding principles I have outlined for a SharePoint implementation (realize these are not the only categories, some may need to be added or some may not be needed, depending on the purpose of the solution being provided).

Last post we reviewed the General and Security principle categories, this post we will look at the following categories:

Document Management Principles

Publishing Principles

So let's get to it...

Document Management Principles

Document Management principles are principles that have to do with the way in which our solution should manage and control the creation and modification of documents in the system.  The reason it is not referred to here as records or information management is really a matter of scope. Document Management principles need to encompass records and information management (RIM), but it should also encompass content that is not part of the document or information strategy.  We are not going to rewrite the RIM (if one exists), but rather we will try to capture the principles behind why the architecture and strategy were implemented.  In addition, we will define principles for content that has not be defined in the RIM (like SharePoint lists) and configuration specific items, like the version control, check-in and check out and draft version rules.

The Document Management Principles are not meant to replace the RIM, but are meant to tie the RIM strategy and governance into the governance of the ECM solution (remember keep it simple and understandable).  In reality, the document management principles are probably one of the most numerous rules you will have in you ECM governance plan, as most of ECM is about the management of documents and content.  As an example of a document management principle, I have my number one rule for all governance (your governance plan will fail without it), "All Content is Owned." as it is outlined below.  Notice it is a principle that encompasses more than just records or documents, addressing all types of content; yet it still applies as a document management process because it affects the way people will work with documents and records.

All Content is Owned
Principle
All content must have a clearly identified “owner”. 

Implication
Users need to know who to contact if content on a site is out of date or inaccurate. The content owner is responsible for all the content in a site and for ensuring it is up to date. Each site should have a clearly defined owner that is visible on the main page of each site.

Publishing Principles

Publishing principles are principles that describe the way in which we plan on using the intranet and published site capabilities of the solution.  It should encompass plans for language variations, the way we are reviewing and publishing content and any other principles that may affect the configuration of the publishing and audience components of the solution.

Publishing principles are about the control of who sees what and when, they provide a foundation for portals and as such are only used when a portal solution is required.  As an example of a publishing principle, I have included "All portal and department site content is reviewed and approved prior to being published", which encompasses the fact that portal and department sites are highly controlled and all changes are reviewed and approved prior to being made available to users.

         All portal and department site content is reviewed and approved prior to being published
           Principle
           All content changes for publishing sites must be reviewed and approved before the changes can be published.
         Implication
         Content owners are responsible for updates, while site approvers are accountable for the correctness
           and appropriateness of the content being published.

Next post we will complete the definitions of the categories for principles and from there will move on to other important governance, like who does what in governance implementation and how we can make principles work within an organization.

ECM Governance - Post 3

Guiding Principles continued

Hi Everyone (or me, myself and I, not sure if anyone reads this...) sorry for the delay in this next post, I having been busy doing and not spending enough time writing about it.  In my post 2, we examined the idea of guiding principles and how they are used to set a foundation for our ECM.  We identified several categories or "Areas of Impact" that these principles could be separated into and this week I would like to start by detailing the intent of each of those categories.

General Principles

The general principles are principles that do not fall into any other category, they are usually the least specific (or most general) and often refer to governance rules and policies and how you intend to use them.  A good example of a general rule is the scope of the governance plan or how we intend to apply principles as a general rule.

For example, we want consistent governance across the entire solution and exceptions need to be recorded whenever a site or site collection does not follow the set of policies defined.  In that case, we can create a general principle to define that need:

Governance Scope
Principle
All governance principles, policies, standards and training are tied to the scope and intended purpose of the entire solution. Governance applies equally to all sites and all site areas.

Implication
While some policies will be enforced across the entire organization, others may be determined by each site owner. The Governance document is not intended to define the site specific policies, but is intended to provide the foundation for all sites. Deviation from the governance policies is by exception only and should be recorded and approved by the steering committee prior to implementation.

Security Principles

Security Principles deal with the need for security and how we plan on using security in our solution.  We address things like the security architecture, the use of roles, external access and permission management as security principles.  It is important that we keep security principles as general as possible, to allow for better granularity at the policy and configuration level of the solution to meet the organizations security needs.

As an example we can look at a principle that is common to any governance plan, the use of roles to manage permissions within the solution.  Again the principle is defined and then the implications to the way the solution will be used are outlined.

Role-based Security Model
Principle
Use of a Role-based security model will govern access control and permissions to the SharePoint Portal.

Implication
Users may have different permissions on different sites or areas of the site, which has an implication for both governance and training. This permission is based off the roles that are assigned at any given level. Direct permissions should not be used; if it is found that direct access is being provided, the roles should be reviewed to determine if a GAP exists in the role structure. If a GAP exists, a new role should be defined to prevent the future need for direct security permissions.

In my next post, I will go over the remaining principles Document Management Principles, Publishing Principles, Collaboration Principles, Business Process Principles and Esthetic Principles. Also if you want to learn more in person, I will be presenting on governance at the SharePoint Summit Vancouver 2013, October 28 & 29, I hope I see you there!

ECM Governance - Post 2

It has been a few days (and a weekend) since my last post, which for me is a lightening fast response.  In this weeks post, I would like to continue along the ECM governance work we started and delve to the core of what defines governance.

Guiding Principles

If you want to consider implementing governance of any type, you are going to need to define a foundation on which we can build our rules for how things will be governed.  As an example, our society is governed by legislation and laws, but in reality, legislation and laws sit on a morale foundation for their existence.  This morale base can be referred to as the principles of our society or the "Spirit of the law".  As society defines the morale base and politicians and law makers interpret the morale base to make the laws and legislation, so to does the business define the guiding principles for ECM.  The actual interpretation of the guiding principles into the making of rules will come later on when we talk about the job of the steering committee, but I think you already have an idea of their role.

In the case of ECM governance, the foundation needs to be clearly defined through what we refer to as guiding principles.  The guiding principles are general rules that help guide us toward the vision we defined in our previous weeks exercise.  With each Principle we have two parts, the definition and the implication.  The definition defines what the principle intends to set rules around, while the implication provides context and understanding of how the principle will affect business users.  If we look at an example (one that should exist in all governance plans), we can see how the principles provide a foundation for use.

All Content is Owned  

Principle
All content must have a clearly identified “owner.”
Implication
Users need to know who to contact if information is out of date or inaccurate. The owner is responsible for the content in a site and for ensuring it is up to date.

This is a simple principle, but the implications can be quite extensive in an organization.  As mentioned in this basic example, ownership implies accountability for content and all content must be owned.  Notice the principle is short and concise, while the implication should be as detailed as needed to ensure that it identifies all the areas affected by the principle.  Our example is currently not detailed in the implication, but that is because the implications are typically specific to each organization.

If we were to look at these principles they can be categorized into several areas of impact.  These areas are as follows:

• General Principles
• Security Principles
• Document Management Principles
• Publishing Principles
• Collaboration Principles
• Business Process Principles
• Esthetic Principles

Each of the above areas cover off the usage and capabilities of the ECM, but additionally help you guide and focus on rules that are important to an ECM.

In our next session, I will examine each of these principle areas and outline the types of principles that you would expect to see in an organization.  For all our future examples, I will use SharePoint as the ECM of choice, though these principles could be applied to any ECM.

ECM Governance - Post 1

Introduction

If you were ever looking for a main cause for the failure of SharePoint implementations, look no further than ECM Governance.  Over the next couple weeks I am going to share some insights I have experienced with governance of enterprise content and what organizations need to do to ensure the successful implementation and use of solutions like SharePoint and OpenText Content Server.

I am a solution architect who has been working in SharePoint and OpenText (and integrating the two) for many years.  I have seen many implementations fail and they all stem from the same cause, a lack of governance.  It isn't just that organizations fail to plan, though that is part of it; it really has to do with how the organization prepares for the changes that a new system brings.

There is nothing worse than building a system and just letting everyone do whatever they want with the system.  Not only does it breed anarchy, it guarantees a poor user experience and a failed result.  The failure to plan is why so many organizations have no governance in place; we need to think ahead and decide how we are going to steer people towards proper use of the solution, that steering or guiding of people is known as governance which makes sense when you consider the source of the word.

The word governance derives from the Greek verb κυβερνάω [kubernáo]which means to steer and was used for the first time in a metaphorical sense by Plato. It then passed on to Latin and then on to many languages. (Origin from http://en.wikipedia.org/wiki/Governance)

In a modern sense, governance is the act of governing.  It involves determining where the organization needs to be and the rules that need to be followed in order to get there.

The Hydra

Every organization has its own ideas and reasons for using a system and this driving force is where we need to start when we talk about governance.  This driving force is actually a multi-headed beast, hence the section title.  The reason it is a Hydra has to do with the organization itself, companies are setup in silos, based on function and there is no way around it.  Engineers will use a system differently from accounting and so on.  In order to figure out the direction the organization needs to take, you are going to need to involve every group that is going to use the system.

Once you have the reasoning behind each groups use of the system, you can begin finding a commonality to their use.  This commonality will define the "Vision" of your governance plan.  It is the core of how the organization will use the solution, while the uniqueness of each group will provide variances that will be used later on in the governance definition process.

If we were building a governance plan, we now would have two sections ready to fill in, the business cases, which summarize your finding from speaking with each group in the organization and the vision, which defines the direction we need to take the solution.

Next Week

Next week I will explore the idea of guiding principles and how we can make those principles a reality in your organization.