Tag Archives: Project Test Plans

New PM Articles for the Week of March 11 –17

Posted on by
Reply

New project management articles published on the web during the week of March 11 – 17.  Dave and Sandra read all of this stuff so you don’t have to!  Recommended:

  • Andy Jordan reminds us that the way we deal with stressful situations is what defines us as leaders.
  • Elizabeth Harrin and Phil Peplow identify six barriers to customer centricity.  Extracted from their book, “Customer-centric Project Management.”
  • Peter Tarhanidis asserts that the customer mindset is always right.
  • Shim Marom presents a decision tree on “Should you attend that meeting?” courtesy of Elizabeth Grace Saunders.
  • Gary Laverty reviews Charles Tryon’s third edition of “Managing Organizational Knowledge.”
  • Frank Saladis has a new book out, “Positive Leadership in Project Management.”
  • Samad Aidane interviews Lina Echeverria, author of “Idea Agent,” 63 minutes.  Also  Geoff Trickey on risk personality types, 45 minutes.  Both safe for work.
  • John Simko shares specific criteria when doing nothing is the appropriate action.
  • Dave Prior continues his interview with Personal Kanban author Jim Prior.  Just 25 minutes, safe for work.
  • LeRoy Ward notes that, if your organization isn’t good at project management, Agile practices will like make a bad situation worse.
  • Ben Ferris shares five tips for making better decisions.
  • Bruce Benson notes that finding the root cause of your current problems is the first step; looking at alternatives comes later.
  • Chuck Morton explains risk buffers, using the example of a daily commute.
  • APQC has released a best-practices study called “Effective Project Management Offices.”
  • Roz Baker lists the bare minimum fields required in a defect log.  Her definition of “PICNIC” is at the bottom, next to the smiley face.
  • Andrew Makar presents a great tutorial on how to create a custom status report within Project 2010.
  • Sue Cochran creates a Project Charter primer by defining the core charter
    requirements.
  • Whitson Gordon sings the praises of Evernote.  (And so do I!)
  • Brett Beaubouef explains the basic equation of requirements management: What + Why = How.
  • Patrick Richard shares insights from a Harvard Business Review blog post, on why employers aren’t filling their open jobs.
  • Toni Bowers has a short list of meaningless phrases you should remove from your resume.  Like “responsible for …”
  • Chip Camden addresses the question of whether age-ism is a factor for us IT consultants.  And then he shaves off his beard!
  • Amanda Augustine has some pointers for IT types who need to perfect their pitch.  Elevator pitch, that is.
  • Srinivasa Rao has been observing the behavior of his Generation Y colleagues, and thinks they will change the way projects are managed.
  • Venkat Rao addresses the biological aspects of curiosity, and ranges from boredom to the destruction of the universe.  Long, but a worthwhile read.

Enjoy!

Perfection is Over-rated

Posted on by
Reply

People who have known me any length of time have probably heard me say that perfection is over-rated.  Some folks think I’m joking, but I’m not.  The plain truth is that there is a certain point – call it “good enough” – where you should stop polishing.  Generally, the quality / cost curve is an asymptote, meaning the next unit of cost gives you an ever smaller improvement.  Those who keep struggling for incremental improvements beyond that quality goal are simply wasting resources, especially time.

The challenge for practicing IT project manager is to work with the stakeholders to get agreement on what is good enough.  And then once that target is reached, to get the perfectionists to move on.  Because perfection, delivered too late, is a complete waste.

An Opportunity to Re-start Requires a Transition Plan

Posted on by
Reply

I got a call from our VP of Delivery on Wednesday.  One of our west coast customers is just beginning two weeks of end to end system testing, and based on how things are going, they’ve decided that they were going down the wrong road.  Among other decisions, they’ve made some changes to roles on their project team.  They’ve assigned a new internal project manager from their IT department, to allow the former PM to focus on her SME role.  This leadership change will give us the opportunity to transition our management of the project from the current east coast-based engagement manager to someone based on the west coast.  I was asked to help support the transition, as an “ombudsman.”  As Bryan put it, “You’ll at least get a blog post out of it.”

Note that this isn’t a “rescue” of a “failed” project.  We are discussing this among ourselves as an opportunity for a “partial re-start.”  In essence, the customer has learned a lot about how they should do business, and they’re going to implement those lessons learned, with our help.  One of the most valuable benefits of an iterative prototyping methodology like Workday’s is that you can learn a whole lot from actually using a prototype, and then decide to build a new prototype using a very different set of assumptions and decisions.  That’s what’s happening in this case; they’ve learned enough from working with the current prototype that they want to make some pretty significant alterations to the business process workflows, roles, and organization model.  So we’ll use the lessons learned, recycle much of the configuration work we’ve already done, and build a new prototype using the new decisions and a fresh load of data. In a few weeks, we’ll be ready to start end to end testing again.

Naturally, this is going to invalidate our old plan, especially the schedule.  So we need a new plan, but first, we need a transition plan; a structured approach to help us create that new plan over the coming week or so.  The key steps for a transition plan include:

  • If they haven’t already done so, stop work.
  • Get the core team together and do a little “getting to know you” for the benefit of the new members.
  • Review the project scope, including original and any proposed or approved change orders. Any additional changes to consider?  Any components to eliminate or defer to another phase?
  • Review their design decisions, as documented.  What changes are under consideration?  Drive out the reasons for them, in order to support communications with the stakeholders.
  • Review work in progress and completed to date, including re-work planned or anticipated.  Does the test plan need additional work?  Any changes needed related to data conversion, validation, or how historical records will be handled?
  • Review issues, both closed and open.  Any to add, re-open, or re-prioritize?  Have any risks metastasized as issues?
  • Based on the above and potential schedule conflicts, consider a new go-live date.  Clearly document the reasons for the change, to support communications to the stakeholders.
  • Based on the go-live date and other changes, re-plan the schedule.  This only sounds backwards; they need to go live at the beginning of a quarter.  The schedule should enable the go-live date.
  • Based on the new schedule and staffing changes, update the communication plan and determine how you’re going to re-engage the stakeholders.  Get the key meetings on the calendar.
  • Update the training plan, for the new team members.  Get them skilled up!
  • Review and update the roll-out / change management plan.
  • Based on all of the above, review the risk register.  Have any new risks become apparent?  Any new risk strategies to consider?  Any other adjustments to make?
  • Based on all of the above, review and update the budget, both consultant costs and internal hours and costs.
  • Review with the sponsor and executive committee, and ask them to give their full approval before proceeding.

While some projects go exactly as planned, most require at least some mid-course corrections.  And of course, some require more extensive corrections than others.  They key is not to “bull your way through,” or let anyone get caught up in blamestorming, but to lead the project team toward a clearer vision of the end state.  And the way to begin that newly refreshed journey is to stop and take a long, careful look at the map.