Month: January 2013

Date Driven Programs – Part 1

If you work in the Information Technology Services Industry, sooner or later you will run into a project that’s driven purely by dates and milestones.  The challenge with such projects, is that the dates and milestones where pre-defined during the initial planning phase of the project or during the RFP where the customer asked for a work plan with milestones.  For the scope of this blog, project and program will be used interchangeably.

What are the dates and milestones missing?  Simply, expert or quasi expert estimates from the vendors and domain experts.  The team that answered the RFP or performed the initial project planning as part of a Program Management Office (PMO) provided a guesstimate (guess estimate).      Granted, all projects and programs need a project plan with an initial baseline so that the project teams can kick-off phase of their relative projects.

A living “schedule”: The big mishap here – is that the schedule does not become a living document due to contractual constraints or the political cloud that surround all organizations.  Often, delivery dates and milestones are unchangeable.  Our PMP governing body is completely ineffective when the schedule is not managed.  Schedule management is the key to a successful project/program.

Scope Creep: The customer wants additional functionality that’s outside the statement of work or project charter. With a weak PMO, this will cause the project to fail because the project teams will be increasing their scope.   Scope management is the key to successful program delivery.   Without scope management, the project teams will be aiming at a moving target.

Schedule Slippage: When the project starts to slip to the right – the System Integrator or the Vendor will make the case to add more resources with justifiable metrics and other pertinent decision making data.  From the customer’s perspective, this is a win-win situation; “you add more consultants and we get the functionality that we need”.  This is not the case.  This is one of the biggest pitfalls in program management and in non Agile programs. This combination is lethal to the success of program.  Here are the misconceptions with such an approach.

  • Mythical Man Month – “Adding more resources to a project that’s already late, will delay the project even further” Why?  Because valuable resources that are delivering functionality will have to come of the assembly line in order to train the new resources. (Fred Brook –
  • Delivery Team Coverage: Since the schedule is not being managed, the delivery team will have to work  over-time (OT) in order to make up for the lost time that they never had to begin with.  OT – only works in the short term before the team enters the law of diminishing marginal returns.  What I mean by this is that the Production Index or Velocity for a project team will reach its climax at a given point in time and the productivity will not increase but rather decrease due to fatigue and other factors  .Work Life Balance for the delivery team will be non-existent. (I have live through several of these projects)
  • Got Middle-Management (MM)? –  If you are a delivery manager and you can’t manage the Work Breakdown Structure (WBS) nor the schedule; then, you are set up to fail.  The challenge is that the WBS and project schedule are not realistic nor portray the actual tasking that it’s taking place.   This leads to the status reporting and more status meetings.  The latter part drives most teams away from interfacing with the “status keepers” and alienates the delivery team from MM.  The “us” versus “them” culture starts to take place and the delivery team will start to become dysfunctional.
  • Got Status? – Anytime a project slips, the hierarchy of reporting becomes greater and more time consuming.  Everyone, who never showed interest on your effort will now zero in on your team and add additional organizational pressures.  Valuable resources will have to allocate additional time for status meetings that were non-existent before the slip.

Next Post will have recommendations on how to deal or manage such challenges.