Search This Blog

Wednesday, September 28, 2011

Sharepoint Part 2: Custom Project Systems on a Shoestring

Develop your own project systems using Free Tools, just add labor

Designing the Solution
In Part 1 we discussed the need for a custom project system. Your needs may be somewhat different than ours, but many of these ideas may apply to you or be a useful reference as you consider building your own custom system.


Requirements first! 
Based on your prior experience, interviews with your team, stakeholders and other inputs, you will come up with a comprehensive laundry list of what you need your system to do for you. Because that is what it is for - to serve a need, make your work and projects easier to manage. You want to build something that works as you need it - not try to shoehorn your processes into something that does not fit. People will get frustrated and not use it. So make sure you consult the people who will be using the system.


Our laundry listed included the following:


Project/Deliverable Tracking through the full lifecycle

  • Project Initiation & Planning
  • Project Execution/Delivery
  • Acceptance Testing
  • Project Closeout/Acceptance
  • Warranty
  • Accommodate both Service and Deliverable based work

Time Entry, Billing and Invoice Support

  • Time entry for short and long duration tasks
  • Ability to capture (and recover) pre-PO time spent
  • Support client billing requirements
  • Weekly client billing
  • Roll-up statistics, filtering, searching etc.
  • Support for reconciling invoices with client time system
  • Associate with Purchase Order, SOW and Contract

Keep it simple - Single points of team interaction

  • Projects administered by PM
  • Team members work with Assignments under Projects

Many custom views per list, all filterable using built-in Sharepoint capabilities


  • Projects by status type
  • Assignments by owner / status type
  • Billing Events by processes status
  • And dozens more, growing as needed over time

Custom workflows to automate the processes and keep things moving
  • New Project
  • Updated Project
  • New Project Assignment
  • Updated Project Assignment
  • Held Time Update
  • New document
  • Processed Billing Event
  • Email notifications
Automated Scripting (Manual and in Workflows)
  • Create document folders/files with metadata (links to Projects)
  • Updating assignment resources based on change of project resources
  • Cascade cancelled projects to "close" assignments etc.
  • Other maintenance and update scripts to manage Sharepoint
And many more details.



Ok, you have the list, now what? Don't start developing just yet.


Model it!
How does the laundry list fit together? You need to make a model of you you see things working together, what information needs to be collected, how status changes, how information needs to be exchanged, etc.


Not sure where to start or how to design a good process model? You may know a good business analyst who can do this, or an experienced process designer.


Steps:
1) Map out the high level design ideas - i.e. the Big Picture. Use mind-map software, or pen and paper.


2) The information and process model needs were then broken down into logical “object” type groupings, each of which would become a custom list in Sharepoint, which would be linked to other lists during development. 


3) The workflow was diagrammed out, and the process states defined accordingly. 

Here is a series of process workflow diagrams we used to map out our processes, covering the different transitions and work types. (There will be a more details on implementing the workflows in Part 4).


Project Initiation Phase
This phase covers the initial efforts required to bring a potential project from concept through to formal estimate. Note that depending on the engagement, the customer may be writing requirements, or we will as a billable service.



Project Execution: Service Model 
This supports both immediate and scheduled future assignments such as training engagements or on-site consulting services.



Project Execution: Deliverable Model
This phase covers the primary activities in deliverable-based projects, including internal QA cycles prior to customer delivery. This phase completes with the first deliverable hand-off for customer testing.


 Project Execution: Acceptance Testing
This phase encompasses the customer test/vendor revision cycles, through to project/deliverable completion and acceptance.

 Warranty Work
With deliverable based projects, there is a limited warranty period, and this workflow supports the ability to track warranty work separate from normal test/revision cycles.


Coming next:
Part 3: Building the Structure: Sharepoint Lists
Part 4: Process Workflow Design
Part 5: Implementing Custom Workflows with Sharepoint Designer
Part 6: Advanced Workflows with PowerShell
Part 7: Hosting tips, Email & Notifications
Part 8: Doing it Yourself - Recommendations
Part 9: Using what you've built - more free enhancements

Go back to:
Part 1: The Need

For more information or questions, contact:

No comments:

Post a Comment