From Business Requirements to Technical Scope
Upcoming SlideShare
Loading in...5
×
 

From Business Requirements to Technical Scope

on

  • 2,050 views

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 ...

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.

Statistics

Views

Total Views
2,050
Views on SlideShare
1,900
Embed Views
150

Actions

Likes
1
Downloads
14
Comments
0

4 Embeds 150

http://www.joiningdots.com 143
http://www.linkedin.com 3
http://www.aetio.com 3
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

From Business Requirements to Technical Scope From Business Requirements to Technical Scope Presentation Transcript

  • BUS303 From Business Requirements to Technical ScopeAlign the dependencies that will determine thesuccess or failure of your SharePoint project Sharon Richardson joiningdots.com Joining Dots @joiningdots
  • This presentation was originally delivered at theInternational SharePoint conference held in Londonduring April 2012This is a modified version formatted for Slideshare.Animations have been removed and some text has beenadded (in this colour) to help with the lack of presenterwhen viewing online… The original presentation lasted 1 hour. Additional noteshave 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 thecontent focused on understanding the dependencies thatwill influence the resources required to deliver a project.Or rather, what causes ‘scope creep’ that can stretchyour available resources and create risk for the project.This content has been taken from a workshop I deliver forclients during the early planning stage of projects. It can beapplied to any information and knowledge-managementplatform but the supporting talk this time was tailoredspecifically to SharePoint projects. (Delivered at a SharePointconference.) The target audience was decision makers andproject management roles rather than implementation.
  • Most projects are startingfrom one of two points:1. A need to meet businessrequirements 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.com2. This is not the strongest business case to be starting frombut not an uncommon one either for SharePoint projects…
  • So how do yousquare thecircle? Business Requirements Technical Scope
  • SharePoint providesboth a platform asthe base and sitesthat can support a Businessrange of solutions Requirements Technical Platform Solutions Scope
  • …it’s rarely one platform and usually lots of different Business solutions… Requirements TechnicalPlatform Solutions Scope
  • Key message: don’t get hooked up on the details of the platform. It’s the easy part of the technical scope…Business Requirements to Technical ScopePLATFORM
  • Whilst the number of base platforms may vary, the decisions atthis level are not complicated… Extranet Intranet Projects My Site Profile Teams AppsWeb Portal Sites Profiles Organisation Group Platform Individual
  • Platform ResourcesIntranet //intranet Capacity Planning • PerformanceTeams &Projects //sites • Availability • StorageProfiles & • Infrastructure //my‘My Site’ Architecture/Design • Site hierarchiesSpecialist //apps • Shared services Apps • Standards
  • Key message: solutions are where the devil can be in the details… 50,000 ft views don’t always translate into comfortable landingsBusiness Requirements to Technical ScopeSOLUTIONS
  • The first culprit: the ease with creating an outline of requirementsusing 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 isno defined framework to measure. Just because requirements areeasy to visualise or articulate doesn’t guarantee a simple workingsolution to build…
  • It’s harder to change Perspective perspective than to Old New change position. And nearly impossible to do both in one go. New And often, SharePoint projects try to do both.Position Most likely approach to fail… Change position first. Old Source: Strategy Safari by Mintzberg, Ahlstrand and Lampel (1998)
  • Example: moving from Perspective docs and file shares Old New 1. One of the most common scenarios for deploying SharePoint is New to shift away from file shares and poorlyPosition managed (often duplicated) documents buried in deep folder hierarchies. Old
  • Example: moving from Perspective docs and file shares Old New 2. Going straight to social media is hardest shift. Requires a big New culture change.Position Changing both the format: from docs to web pages; and the process: real-time Old updates, instant feedback instead of approval/review process
  • Example: moving from Perspective docs and file shares Old New 3. It’s much more common to see a shift to sites containing New document libraries and using tags to classify.Position Still documents but a very different process to manage Old …but changing perspective is hard without good reason. Many sites fall back to using folders instead.
  • Example: moving from Perspective docs and file shares Old New 4. Introducing forms and workflow to improve paper New processes one of the easiest ways to createPosition early value Shift from documents to forms but still Old working with files and the normal processes. Perspective is the same and easy use.
  • All need much moreSolution Resources than a technical scope Records Technology Mgmt Data • Platform Apps • Features Knowledge Information Sharing News • Management Updates • Interaction Collab Activities People Online • Training Forms Business • Culture Scorecards
  • Business Technical TechnicalRequirements Scope Scope Business requirements to Technical scope – squaring the wrong circle. Scope can always grow to meet Available requirements. Resource It’s available resources that will constrain what can and can’t be done and determine the end result
  • 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 resourcesBusiness Requirements to Technical ScopeDEPENDENCIES
  • Dependencies• Information Management• Interaction Design Impact on• Training Resources?• Support • Time• Content Migration? • Budget• Process Redesign? • People• Culture? • Technology
  • Feedback Loops S = Supporting, increase one increases the other O = Opposing, increase one decreases the other Business Training Requirements O & Support S S This is a very S simplified version O User Effort of a causal loop diagram to Technical demonstrate Scope S some of the S O dependencies beyond technical S Information scope Management Information S S Compliance Value
  • Feedback Loops S = Supporting, increase one increases the other O = Opposing, increase one decreases the other 1. Start with the desired outcome – to create value from information Business Requirements Increase business requirements S increases effort placed on users. S Increase user effort O User Effort reduces information value. More effort Technical required, more likely Scope to make mistakes O 2. Convert those requirements into technical scope instead. The more technology can do, the less user effort is required… (technology should help automate) Information Value
  • Feedback Loops S = Supporting, increase one increases the other O = Opposing, increase one decreases the other 3. Better information management Business can (should) increase value. But, if Requirements place demands on users (e.g. to tag S content), increases user effort… Automating IM through S technology can offset O User Effort some of that effort (but never all of it) Technical Scope S S O S Information Management4. Information Management andTechnology have a tight relationship. If Informationtechnology is too basic, can’t do much IM S Valueeither. More IM increases technical scope.Can reach a breaking point…
  • Feedback Loops S = Supporting, increase one increases the other O = Opposing, increase one decreases the other Business Training Requirements O & Support S S S O User Effort 5. If place more demands on users. Need to consider Technical training and support Scope S S to help minimise O mistakes… S Information Management Information S Value
  • Feedback Loops S = Supporting, increase one increases the other O = Opposing, increase one decreases the other Business Training Requirements O & Support S S S 6. Compliance is a O User Effort common need that may not be articulated in initial Technical business requirements but will force how Scope S S much IM is required O and influence all dependencies… S Information Management Information S S Compliance Value
  • Feedback Loops S = Supporting, increase one increases the other O = Opposing, increase one decreases the other Business Training Requirements O & Support S S This is a very S simplified version O User Effort of a causal loop diagram to Technical demonstrate Scope S some of the S O dependencies beyond technical S Information scope Management Information S S Compliance Value
  • To summarise…
  • From Business RequirementsTo Technical Scope• 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
  • Next steps:Apply constraints to be able to lock down your phase 1deliverables 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
  • Posted to:http://www.joiningdots.com/blog/2012/04/why-technical-projects-fail/ Sharon Richardson sharonr@joiningdots.com @joiningdots