Just Enough PM


Published on

Presented at the NJ PMI Symposium 2008

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Just Enough PM

  1. 1. “ Just Enough” Project Management David Lipper, PMP & CSM Stan Lipper, PMP
  2. 2. Traditional approach <ul><li>One enterprise-wide methodology is chosen for the company </li></ul><ul><li>All project teams are required to provide a minimum set of documents </li></ul><ul><li>All teams are required to have a minimum number of status meetings </li></ul><ul><li>All teams must have representation from certain groups within the organization </li></ul><ul><li>All documents must be stored in the same repository </li></ul>
  3. 3. Advantages of Traditional approach <ul><li>Communication is standard </li></ul><ul><li>Documentation is standard </li></ul><ul><li>Approach is standard </li></ul><ul><li>All documents are stored in the same place </li></ul>
  4. 4. Disadvantages of Traditional Approach <ul><li>Not all projects are the same </li></ul><ul><ul><li>By definition projects are unique, yet companies enforce standards that inhibit uniqueness </li></ul></ul><ul><ul><li>It is hard to make a one size fits all methodology when exceptions happen most of the time </li></ul></ul><ul><ul><li>Projects retrofit information into document standards that sometimes make them useless </li></ul></ul><ul><li>Sometimes different tools require different storage methods (blogs, ms documents, wikis, diagrams) </li></ul><ul><li>Project sometimes take longer because of the methodology chosen </li></ul><ul><ul><li>Too much or too little buy-in from the business </li></ul></ul><ul><ul><li>Too much or too little documentation </li></ul></ul><ul><ul><li>Too much or too little prototyping </li></ul></ul>
  5. 5. “Just Enough” IS <ul><li>Applying the right style to achieve scope, time, cost, and quality goals </li></ul><ul><li>Choices of methodologies, tools, techniques </li></ul><ul><li>Right-sizing the methodology chosen </li></ul><ul><li>Best fit on a project level </li></ul><ul><li>A communication plan at the project level that achieves success </li></ul>
  6. 6. “Just Enough” is NOT <ul><li>A trimmed down version of a methodology </li></ul><ul><li>Minimum amount of effort all PMs should perform </li></ul><ul><li>A way to save money on project management </li></ul><ul><li>A way to avoid process </li></ul><ul><li>Controlled chaos </li></ul>
  7. 7. A comparative look <ul><ul><ul><li>Traditional </li></ul></ul></ul><ul><ul><ul><li>Prescribed consisted methodologies </li></ul></ul></ul><ul><ul><ul><li>Documentation standards </li></ul></ul></ul><ul><ul><ul><li>Structured meetings </li></ul></ul></ul><ul><ul><ul><li>Defined repeatable processes </li></ul></ul></ul><ul><ul><ul><li>Completely defined requirements </li></ul></ul></ul><ul><ul><ul><li>Defined and documented scope </li></ul></ul></ul><ul><ul><ul><li>Defined participation by phase </li></ul></ul></ul><ul><ul><ul><li>“ Just Enough” </li></ul></ul></ul><ul><ul><ul><li>Methodology selected to best fit the project </li></ul></ul></ul><ul><ul><ul><li>More collaboration with minimal documentation </li></ul></ul></ul><ul><ul><ul><li>Work sessions replace structured meetings </li></ul></ul></ul><ul><ul><ul><li>Customized processes for each project </li></ul></ul></ul><ul><ul><ul><li>Requirements evolve throughout releases </li></ul></ul></ul><ul><ul><ul><li>Scope managed/modified with business needs </li></ul></ul></ul><ul><ul><ul><li>Active participation throughout </li></ul></ul></ul>
  8. 8. Picking the right methodology <ul><li>If the goals are clear, the requirements are set, the project is complex and there is no way to deliver some functionality early, then go waterfall…you can’t deliver half a house </li></ul><ul><li>If there is ambiguity and a changing environment and you need to add value quickly…then apply Agile. Deliver a row boat…then add an engine…then add a cabin </li></ul><ul><li>If the business is risk tolerant, the tech team is very savvy, and the deliverable time is more important than enterprise standards…then apply Extreme </li></ul>
  9. 9. “ Just enough” project management <ul><li>Develop a complete understanding of various methodologies </li></ul><ul><li>Establish a PM Framework that is separate from the development methodology </li></ul><ul><li>Assess the project to determine the right methodology </li></ul><ul><li>Set project boundaries not methodologies </li></ul><ul><li>Architect the development and PM approach for each project </li></ul><ul><li>Use a hammer to hit a nail but use a wrench to tighten a screw…use the right tool for the job </li></ul>
  10. 10. Setting boundaries not methodologies <ul><li>Yes </li></ul><ul><li>You must produce a plan for how the project will be managed. That plan will describe the documents needed </li></ul><ul><li>Establish a communication plan to define the most effective communications for a specific project </li></ul><ul><li>Define which groups will participate and the nature of the participation will be defined in the planning phase </li></ul>No You must produce these documents… You must have weekly status meetings You must have representation from certain groups within the organization
  11. 11. Methodology choices <ul><li>PMBOK </li></ul><ul><ul><li>Setting a standard language for projects </li></ul></ul><ul><li>Waterfall </li></ul><ul><ul><li>A methodology where the product is delivered at the end </li></ul></ul><ul><li>Agile </li></ul><ul><ul><li>A methodology which produces product deliverables in fixed sprints and works well in ambiguous environments </li></ul></ul><ul><li>Extreme </li></ul><ul><ul><li>A methodology to just get it done…with limited documentation </li></ul></ul>
  12. 12. One size doesn’t fit all <ul><li>The waterfall methodology problem -- A project to deliver a CD writer that creates FDA documents took 16 months because of the documentation…the actual work was less than a month </li></ul><ul><li>The Agile Methodology problem – Some infrastructure projects only have one deliverable but they get retrofitted into agile and don’t take advantage of interim product deliverables </li></ul><ul><li>The extreme methodology problem – A very complex project is jump-started by the development team and they never produce what the business needed because they never documented the requirements </li></ul>
  13. 13. A Project Management Framework <ul><li>Covers all of the phases of the PM Life-Cycle </li></ul><ul><li>Contains forms, checklists, sample processes, templates, and tutorials </li></ul><ul><li>The framework should be flexible (for any type of project) and scalable (for any size of project) </li></ul>
  14. 14. Working with “Just Enough” <ul><li>Depending on the nature of the development project: </li></ul><ul><ul><li>Select the best development methodology </li></ul></ul><ul><ul><li>Architect a PM approach that: </li></ul></ul><ul><ul><ul><li>Adheres to the PM framework </li></ul></ul></ul><ul><ul><ul><li>Contains enough to control the project with minimal overhead </li></ul></ul></ul><ul><ul><ul><li>Customized to best fit the characteristics of the project </li></ul></ul></ul>
  15. 15. Conclusion <ul><li>“ Just Enough” models the project not the organization </li></ul><ul><li>Doing “Just Enough” will minimize the project management overhead </li></ul><ul><li>“ Just Enough” is a new way to look at your portfolio of projects </li></ul><ul><li>Having different methods for solving problems keep employees engaged </li></ul>