project communications -...
TRANSCRIPT
Project Communications
An Agile Approach – Before, During and After
Mark GerowDirector, Applications & Business Process
Fenwick & West LLP
Agenda…
• Part 1: An Agile Approach
• Part 2: Communicating Using SharePoint
If time permits…
• Part 3: Streamlining communication using workflow
Part 1: An Agile Approach
Based on the article “Improving Project Outcomes Using SCRUM Methodology” ILTA Peer‐to‐Peer
http://www.iltanet.org/communications/article.aspx?nvID=000000010805&snvID=000000011005&h4ID=000001181305
We’ve all been there…
Enter Agile
How Agile DiffersTraditional Agile
Requirements are assumed to be known up‐front and held constant until completion. A “change management” process is required, and treats change as the exception, not the rule
Assumes Change. Provides mechanisms for frequent course corrections.
Once requirements are set, the project team is free to determine the order of work to suit their needs
Work is performed based on stakeholder‐driven priorities. Stakeholder gets to decide what gets done; project team decides how to do it.
It’s assumed that until all work is complete, the firm won’t realize the benefits of the project. Some interim benefits may accrue, but this is a happy accident, not a planned outcome
Focus is on completing work incrementally –providing a smoother stream of benefits to the firm
Progress is reported through formal mechanisms such as status meetings and Gantt charts, which are often confusing for stakeholders
Feedback to stakeholder is provided via frequent meetings (every 2‐4 weeks) so s/he can adjust requirements and priorities to meet changing understanding of requirements and business needs
Part 2: Communicating Using SharePoint
Based on the article “Simplify Project Management with SharePoint” for
LAW.COM
http://www.law.com/jsp/legaltechnology/pubArticleLT.jsp?id=1208774507933
The Problem
What’s SharePoint got to offer?
Key Ingredients
A list of deliverableStatus codesIf you will be managing
Multiple projects inA single list
A list containing eachDeliverable to be tracked
Status CodesCode Meaning
1.0 Needs More Definition Not sufficiently defined for project team to begin work
2.0 Pending Defined, but not yet assigned for work, or task has been removed the “In Process” status due to changing priorities
3.0 In Process Work is proceeding
4.0 Complete Project team believes task is complete, but stakeholder has not reviewed and accepted (or rejected) the task deliverable(s)
5.0 Accepted Stakeholder has reviewed the task deliverable(s) and accepted it as complete
6.0 Rejected Stakeholder has reviewed the task deliverable(s), but determined that they do not meet requirements. Note – if deliverable(s) still relevant, status should be reset to “2.0 Pending” – only use “6.0 Rejected” if no longer required
‐‐ Parking Lot ‐‐ An interesting idea or deliverable that the project team wants to keep for future reference, but not something that the team will focus on at this time
‐‐ Cancelled ‐‐ At one time considered relevant to the project, but no longer needed
Task List FieldsField Purpose
Project Looked up from project list – the project this task is a part of
Title A short descriptive phrase
Requested By Stakeholder requesting this deliverable
Description One or more sentences describing the task and deliverable(s)
Project Team Notes Used by project team to record progress and share information about this task
Assigned To Project team member currently working on this task
Status Looked up from status list – the current status assigned
Priority Level of importance of this deliverable – from 0 to 100. Assigned by stakeholder
Target Start Date (optional) Generally discouraged in SCRUM, but may be required
Target Complete Date (optional)
Generally discouraged in SCRUM, but may be required
Part 3: Streamlining Communications Using Workflow
Time Permitting
Thank You!
Mark Gerow