Upload
sharon-richardson
View
1.677
Download
3
Embed Size (px)
DESCRIPTION
Modified version of a presentation delivered at the International SharePoint Conference held in London, April 2012. How to navigate from business requirements to technical scope, the importance of understanding dependencies and feasibility of desired outcomes.
Citation preview
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
BusinessRequirements
SharePoint provides both a platform as the base and sites that can support a range of solutions
TechnicalScope
SolutionsPlatform
BusinessRequirements
…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
Example: moving from docs and file shares
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
Example: moving from docs and file shares
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
Example: moving from docs and file shares
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
BusinessRequirements
TechnicalScope
AvailableResource
TechnicalScope
BusinessRequirements
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
Business Requirements
TechnicalScope
User Effort
Information Value
S = Supporting, increase one increases the otherO = Opposing, increase one decreases the other
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
Business Requirements
TechnicalScope
InformationManagement
User Effort
Information Value
S = Supporting, increase one increases the otherO = Opposing, increase one decreases the other
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
Business Requirements
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
5. If place more demands on users.
Need to consider training and support
to help minimise mistakes…
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
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
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
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/