from business requirements to technical scope

From Business Requirements to Technical Scope

BUS303

Sharon Richardson

Joining Dots

joiningdots.com

@joiningdots

Align the dependencies that will determine the success or failure of your SharePoint project

This presentation was originally delivered at the International SharePoint conference held in Londonduring April 2012

This is a modified version formatted for Slideshare. Animations have been removed and some text has been added (in this colour) to help with the lack of presenter when viewing online…

The original presentation lasted 1 hour. Additional notes have been posted on the web site and are available here:

http://www.joiningdots.com/blog/2012/04/why-technical-projects-fail/

Background Information:

The title of the presentation is a little misleading as the content focused on understanding the dependencies that will influence the resources required to deliver a project. Or rather, what causes ‘scope creep’ that can stretch your available resources and create risk for the project.

This content has been taken from a workshop I deliver for clients during the early planning stage of projects. It can be applied to any information and knowledge-management platform but the supporting talk this time was tailored specifically to SharePoint projects. (Delivered at a SharePoint conference.) The target audience was decision makers and project management roles rather than implementation.

Most projects are starting from one of two points:

1. A need to meet business requirements

Desired outcomes are easy to articulate, but can be very hard to achieve.

You need more than a technical scope to ensure success.

“We apparently already own this, and we want to implement it.”

Source: What’s wrong with SharePoint?, RedmondMag.com

2. This is not the strongest business case to be starting from but not an uncommon one either for SharePoint projects…

TechnicalScope

BusinessRequirements

So how do you square the circle?

TechnicalScope

SolutionsPlatform


SharePoint provides both a platform as the base and sites that can support a range of solutions

TechnicalScope

SolutionsPlatform


…it’s rarely one platform and usually lots of different solutions…

PLATFORMBusiness Requirements to Technical Scope

Key message: don’t get hooked up on the details of the platform. It’s the easy part of the technical scope…

Organisation Group Individual

Portal Sites Profiles

Intr

anet

Apps

Team

s

Profi

le

Proj

ects

My

Site

Extr

anet

Web

Platform

Whilst the number of base platforms may vary, the decisions at this level are not complicated…

Intranet

Teams &Projects

Profiles &‘My Site’

SpecialistApps

//my

//sites

//intranet

//apps

Platform Resources

• Performance• Availability• Storage• Infrastructure

Capacity Planning

• Site hierarchies• Shared services• Standards

Architecture/Design

SOLUTIONSBusiness Requirements to Technical Scope

Key message: solutions are where the devil can be in the details…

50,000 ft views don’t always translate into comfortable landings

The first culprit: the ease with creating an outline of requirements using Excel can lead to …

“I’ve got this simple request for you to build…”

Which is more complex: cucumber or brain?

Intuitively, we assume it’s the brain (I’d like to think so) but there is no defined framework to measure. Just because requirements are easy to visualise or articulate doesn’t guarantee a simple working solution to build…

PerspectivePo

sitio

nOld New

Old

New

Source: Strategy Safari by Mintzberg, Ahlstrand and Lampel (1998)

It’s harder to change perspective than to change position. And nearly impossible to do both in one go.

And often, SharePoint projects try to do both. Most likely approach to fail…

Change position first.

PerspectivePo

sitio

nOld New

Old

New

Example: moving from docs and file shares

1. One of the most common scenarios for deploying SharePoint is to shift away from file shares and poorly managed (often duplicated) documents buried in deep folder hierarchies.

PerspectivePo

sitio

nOld New

Old

New


2. Going straight to social media is hardest shift. Requires a big culture change.

Changing both the format: from docs to web pages; and the process: real-time updates, instant feedback instead of approval/review process

PerspectivePo

sitio

nOld New

Old

New


3. It’s much more common to see a shift to sites containing document libraries and using tags to classify. Still documents but a very different process to manage

…but changing perspective is hard without good reason. Many sites fall back to using folders instead.

PerspectivePo

sitio

nOld New

Old

New


4. Introducing forms and workflow to improve paper processes one of the easiest ways to create early value

Shift from documents to forms but still working with files and the normal processes. Perspective is the same and easy use.

Solution Resources

• Platform• Features

Technology

• Management• Interaction

Information

• Training• Culture

People

RecordsMgmt

KnowledgeSharing

BusinessScorecards

OnlineForms

NewsUpdates

DataApps

CollabActivities

All need much more than a technical scope


TechnicalScope

AvailableResource

TechnicalScope


Business requirements to Technical scope – squaring the wrong circle. Scope can always grow to meet requirements.

It’s available resources that will constrain what can and can’t be done and determine the end result

DEPENDENCIESBusiness Requirements to Technical Scope

If dependencies are not identified and aligned early in the project, they will be assumed as part of the project (‘scope creep’) and stretch limited resources

Dependencies

• Time• Budget• People• Technology

Impact onResources?

• Information Management • Interaction Design• Training• Support

• Content Migration?• Process Redesign?• Culture?

Feedback Loops

Business Requirements

Compliance

TechnicalScope

InformationManagement

User Effort

Information Value

S = Supporting, increase one increases the otherO = Opposing, increase one decreases the other

Training& Support

S

S

O

O

S

O

S S

S

S

S

This is a very simplified version

of a causal loop diagram to

demonstrate some of the

dependencies beyond technical

scope

Feedback Loops


TechnicalScope

User Effort

Information Value


S

S

O

O

1. Start with the desired outcome – to create value from information

Increase business requirements increases effort placed on users.

Increase user effort reduces information

value. More effort required, more likely

to make mistakes

2. Convert those requirements into technical scope instead. The more technology can do, the less user effort is required… (technology should help automate)

Feedback Loops


TechnicalScope


User Effort

Information Value


S

S

O

O

S

S

S

S

3. Better information management can (should) increase value. But, if

place demands on users (e.g. to tag content), increases user effort…

Automating IM through technology can offset

some of that effort (but never all of it)

4. Information Management and Technology have a tight relationship. If technology is too basic, can’t do much IM either. More IM increases technical scope. Can reach a breaking point…

Feedback Loops


TechnicalScope


User Effort

Information Value


Training& Support

S

S

O

O

S

O

S

S

S

S

5. If place more demands on users.

Need to consider training and support

to help minimise mistakes…

Feedback Loops


Compliance

TechnicalScope


User Effort

Information Value


Training& Support

S

S

O

O

S

O

S S

S

S

S

6. Compliance is a common need that may

not be articulated in initial business requirements

but will force how much IM is required

and influence all dependencies…

Feedback Loops


Compliance

TechnicalScope


User Effort

Information Value


Training& Support

S

S

O

O

S

O

S S

S

S

S

This is a very simplified version

of a causal loop diagram to

demonstrate some of the

dependencies beyond technical

scope

To summarise…

• Requirements and desired outcomes rarely translate into a single technical scope

• Understand resource constraints- Time, Budget, People, Technology

• Identify and align dependencies…then (ruthlessly) prioritise requirements

• Seek out potential hidden costs as early as possible (prototyping can help)

• Chunk the project into a series of scopes and deliverables to meet desired outcomes

From Business Requirements To Technical Scope

Apply constraints to be able to lock down your phase 1 deliverables and technical scope:

• Feedback loops help identify dependencies and their potential impact on the desired outcome and ability to deliver. Plus can help expose potential hidden costs not yet accounted for

• Identify responsibilities and who owns the budget for each item. IT shouldn’t be picking up the entire bill…

• Define if need is fixed (must do it all) or variable (start somewhere and grow at a later stage)

• Prioritise requirements and quantify resource

Next steps:

Sharon [email protected]@joiningdots

Posted to: http://www.joiningdots.com/blog/2012/04/why-technical-projects-fail/