Even Data Needs a Green Mentality

I just watched an interview with Kate Parson, a Senior Director at EMC.  She was talking about Project Propel, which replaced their two decade-old ERP solution with a nice, shiny new SAP solution.  The part that really caught my attention was her statement that, early in 2012, they had to start deleting tables in their database, because they ran into “an integer limit.”  They had accumulated so many records that even Oracle couldn’t handle them.  Yes, you read that correctly: EMC, provider of massive storage solutions, couldn’t handle the sheer volume of data records they had accumulated.

I make my living moving customers off of old HR, payroll, and benefits administration solutions and onto a nice, shiny new one in the Cloud.  Naturally, a big chunk of every project is moving records from the old solution to the new one.  We always recommend that customers only move “current” records, rather than attempt to load history.  While you need to retain history records for some period of time, they don’t need to be kept commingled with current records, in the system of record.  They can be stored in off-line databases, with restricted access, or as reports, on paper or in PDF format, or any number of other approaches.  But whatever approach you use, at some point those records will need to be destroyed, in accordance with your organization’s record retention policy for that sort of data.  You guys have a record retention policy, right?

We need to adopt a “Green” mentality for data records.  We need to make proper disposal of old records that have come to the end of their useful lives as much a part of system design and maintenance as disaster recovery.  Ensure that you have a plan to move records from on-line to secure off-line storage at some well-defined point.  Ensure you have the ability to later purge them from off-line storage.  Ensure these activities are scheduled as part of the annual operations calendar.

Of course, some records may need to be retained past their normal lives because of a court order, as part of a legal dispute.  And some types of records may be subject to summary analysis as a class or group, rather than a simple look-up (think Lilly Ledbetter or other sorts of class action lawsuits).  This is why your legal counsel should review your record retention policy, to ensure you keep records as long as required, and no longer.  So the selection of the proper storage tool set for history records has to take into account the potential need for these contingencies.  Be sure you understand all possible uses (and customers) for history records before you settle on a storage medium.

The bottom line here is that proper stewardship of the organization’s data records requires a life cycle mentality.  Just as you have a plan to destroy old hard drives (you do, right?), you should have a plan to manage destruction of old data records.  At some point, all of that data quits being an asset, and becomes a liability; legal, technical, or administrative.  Recognize the risks, and treat them as such.

Things I Learned Managing Fixed Price Agile Projects

When it comes to managing Agile projects, Jesse Fewell is the expert.  He’s one of the founders of the PMI Agile Community of Practice and a senior adviser on the PMI-ACP certification.  And he recently conducted a webinar on managing fixed-price Agile projects.  A fixed-price contract is essentially a vehicle for transferring cost risk from the customer to the service provider.  Consequently, it is incumbent on the service provider to manage that risk, in terms of deliverables, quality, and schedule.

Typically, risk is accepted at a premium, so a well-managed fixed price contract can be more profitable than a time and materials contract with the same SOW.  As the project manager, you are responsible for more than just the deliverables in the SOW.  You are also responsible for triggering invoices for progress payments and managing to the constraints specified in the contract.  Given that I’m currently managing two fixed-price Agile projects, I thought I’d add my observations.

  • When the price is fixed, change management is your only tool for staying out of the red.  Any change in scope has to be documented in a change order, and funded as provided for in the overall contract.  If the menu says dinner comes with soup or salad, you’ll have to pay extra to get both.  IT projects should be managed on the same basis.
  • Have a clear delineation of responsibility with the customer on the process for vetting and approving change requests.  By time the request gets to you, it should consist of “What will it cost us to change …” and it should have already been reviewed by the steering committee as something they are willing to approve funds to get.  Otherwise, you will find yourself typing up someone else’s letters to Santa Claus.
  • On a time and materials contract, activities are billable. On a fixed-price contract, your progress payments will be tied to specific, well-defined deliverablesWell-defined means there is an existing template for this deliverable, and it’s been delivered before on similar projects.
  • A well-written contract will have a clause that each deliverable will be deemed accepted unless specific objections are raised in some number of days.  Ensure your customer identifies who will inspect each deliverable, and briefs them on acceptance criteria and how much time they have to perform the inspection at the beginning of the project.  Make sure they understand their role.
  • Interaction with the customer is a key Agile tenet, but not all interaction is created equal.  Some meetings are necessary in order to produce the deliverables in the SOW.  Other meetings are necessary to manage the project and coordinate work planned and in progress.  Push back on all other meetings, because those are activities, and you’re not getting paid for them.
  • If you are unlucky enough to get a contract with both a fixed price and a fixed delivery date, you must put a due date on every client input, and document every delay.  This is especially true if there are liquidated damages in the contract.  Remind the customer that delays on critical path tasks delay the delivery date, day for day.  Yours are not the only feet facing the fire.
  • If change management is not in your SOW, it is not your responsibility.  But it is someone’s responsibility, and you need to keep one eye on them.  Ensure the customer understands the importance of communication, training, preparations for support of the system in production, and the dozens of other details, great and small.
  • The scope of testing has to be clearly defined, and acceptance criteria specified.  The pursuit of perfection is expensive; don’t let your fixed price lead to enhanced definitions of quality, “since it’s free.”
  • Be very clear on your responsibilities after delivery.  Ideally, it will be expressed in the SOW as a number of hours, over a period of weeks.  In any case, define up front when support begins, and when it ends.

Agile methods produce high quality results via iteration and refinement, but the iterations needn’t be endless. Agile projects can be managed to a cost target based on constraints such as time boxing and clear definitions of “done.”  The key is to be ruthless in enforcing agreed-to definitions of quality and completeness, and ensure your customer is holding up their end of the stick.

The “If/ Then” Risk Statement

Project managers know that risk management is an ongoing process, and risk identification happens throughout the project life cycle.  Of course, one of the basic requirements in identifying project risks is describing each risk in such a way that it is meaningful to management and other stakeholders who aren’t part of the project team.  To that end, a common practice is to document risks as “If / then” statements, in the following format:

IF [Event], THEN [Consequences].

You may remember the definition of a risk as “An uncertainty that matters.”  In this case, the Event is the uncertainty, and the Consequences are why it matters.  The risk statement relates the Consequences to the Event.  As an example, let’s say an interface is being built that will pass “hours worked” for each employee from the timekeeping system to the payroll system.  Obviously, the hours worked is a critical input in order to calculate payroll for those employees who are paid by the hour.  For this reason, the interface must be developed, and testing completed, before payroll system testing can begin.  A risk statement that describes this dependent relationship might be written as:

IF the interface from timekeeping to payroll is not completely tested prior to the beginning of payroll system testing,

THEN payroll system testing will experience a day-for-day schedule slip.

This sentence structure is preferred because it facilitates a qualitative risk analysis.  Articulating the Event so specifically makes it easier to determine the probability that it will occur.  It’s also easier to visualize, making it easier to identify risk response strategies.  Can the risk be avoided, by moving the interface out of scope?  Probably not, since it’s so critical to the payroll system.  Can the risk be transferred, by having a third party develop the interface?  Yes, but unless they are significantly more experienced in this specific task, the probability of the occurrence may be the same.  Can the risk be mitigated, by making the development and testing a higher priority for the team, and assigning resources to assist with preparing test data and evaluating the output of the interface process?  Probably, because that should reduce the probability of the Event occurring.

Articulating the Consequences helps to assess the impact of the Event, in terms meaningful to the project.  For example, a schedule slip of up to two days in the start of payroll system testing might be within the schedule reserve, but more than that would delay the beginning of parallel testing.  This would force the go-live date to be moved out three months, since a new payroll system can only be rolled out at the beginning of a new quarter.  Thus, the impact of a delay of two days would be negligible, but any more than that would impact the delivery of the payroll system by three months.  From this, it is possible to estimate the additional cost of the Event, at each probable delay.  This assessment could then be used to drive whether to mitigate the risk, based on the cost of the mitigation approach under consideration, or accept the risk, without attempting to reduce the likelihood of it occurring.

As you can see, a well-constructed risk statement will make your other risk management chores easier.  It’s also makes it easier to explain the risks you’re managing to the project sponsor, stakeholders, and management.