December 3, 2007 – Lacking Commitment

They stripped a month off my project. Okay, technically I misunderstood them when they said go-live was September. What they meant was there would be a month long parallel run in production before they turned off the old system in September. Either way there were four less weeks of development time.

After sketching out the timeline, System Testing was scheduled for July 18. The four weeks to that date didn’t look long enough to me for the interface team. I wanted desperately to return to the steering committee with evidence to support my suspicions, but when asked, the team assured me it would be ready. Every status meeting I checked. Between meetings I followed up. Always the same answer: “We are on schedule.”

On July 17 we had the pre-System Testing meeting to tie up loose ends, the interfaces being one of them. The technical lead smiled and said with confidence, “We finally did it. The design is complete.” Yes, he said DESIGN! During the somewhat heated discussion that followed it became clear that they were no where near ready to test. The code didn’t even exist. They had said the words but had never committed.

Obtaining Commitment. Before anyone can (or should) commit to anything they need to know what they are in for. Walk through the expectations with the team that will do the work. Ask them for their estimates, timelines and constraints. Deadlines I impose can be dismissed as unrealistic but if the team develops the dates they own the estimate and associated commitments.

Scheduling Commitments. Before finalizing and announcing any dates, put a schedule together to lay out the commitments. Ideally you would use Primavera, MS Project or other tool to detail phases, deliverables, activities and tasks with planned hours and baseline dates. Even without those you can still put a meaningful schedule together. At a minimum, break the effort into pieces (ex. Interfaces A, B and C) and sketch out the tasks to complete them. Lay out the timeline based on the commitment and assign resources to the tasks.

Tracking Commitments. If your team has matured to the point of using actual hours and estimates to complete to rework the plan on a weekly basis, consider yourself fortunately. Many companies aren’t there yet. For everyone else, you can work it using the due dates and percent complete. Each week have the team report on which tasks are completed and the percent complete of started ones. Also have them review the task end dates and confirm they are still realistic. If a task slips, check the ripple effect and have them determine how to get back on track. Projects usually fail at the task level. Keep them in line and you stand a chance of completing on time.

Breaking Commitments. Sometimes commitments can’t be kept. Your team has to know they can tell you when they can’t meet a date. For whatever reason, my interface team waited until it was too late. By communicating the progress along the way adjustments can be made. Scope can be altered. Resources can be added. Alternatives can be discussed. When communicating the disappointing news to your management, have your facts in place. Instead of just saying, “We can’t make it,” spell out:
· Cause of the problem.
· Plans to get back on schedule.
· Proposed new dates.
· Steps to keep the problem from happening again.
· Help needed from management.

To solve our problem we ended up bypassing the interface engines by generating test material until they were completed. With significant sweat and long weekends we were able to meet the aggressive September timeline with a shortened parallel run.