Posts Tagged ‘Milestones’

Milestones are important in any paradigm of project management regardless of what tools are used to assist in project management. Carefully planned milestones go a long way towards success of a project and satisfaction of its stakeholders.

While a project may be reviewed in great detail by looking at the level of tasks, it is the milestones and their dates that aggregate the impact for easy comprehension of the bigger picture.

Now, is there a basis for setting up these milestones in a project?

While it is not exactly a science, some useful guidelines can certainly be framed to help in defining the milestones. A word of caution, of course, is in specific situation, these guidelines may be required to be adapted to fit the occasion.

Here we go:

Every important event in the life of a project is enshrined as a milestone. Usually these events mark the completion of a phase of the SDLC cycle for a module or piece of the system under development.

Associated with a milestone is a deliverable (code, document, bug-list…) of value to the stakeholders.

It is often overlooked the acceptance of the deliverable by the customer is also a milestone. It implies the deliverable is adequately tested by the vendor before delivery and is also sufficiently tested by the customer for its acceptance. The principle applies to all committments required from the various stakeholders for the successful execution of the project. And these milestones represent the committment of their owners (stakeholders) to the project. This must be impressed up on all at the very outset. It is not a solo show by the vendor driving all the milestones.

As far as possible, a milestone has a single stakeholder responsible for the deliverable. For instance, QC testing is normally done by an independent Quality group and hence gives rise to a separate milestone to mark that activity.

Obviously the definition of the milestones and their sequencing are settled jointly by the stakeholders, usually guided by the customer’s priorities and any inherent dependencies and risks.

Often a simple step is missed out of making sure all stakeholders are in the know and in agreement with the schedule of milestones. It has the potential for causing serious consequences. How often do we find the customer has planned his vaccation when the deliverable is required to be tested by him for acceptance!

A corollary of associating a deliverable with a milestone is to also link a quantum of payment by the customer to the vendor commensurate with the efforts towards the milestone.

The milestone’s deliverable must be ‘executable’ (verifiable), must represent a significant addition to the functionality delivered in the earlier milestones. And, even usable especially in the later stages of the project.

For this reason, it is a good practice to ensure the deliverable of the current milestone is completely integrated with the earlier deliverables.

In all but the simpler projects, at any instant of time, activities may be current on more than one milestone.

A key question still remains is: How many milestones should be defined in a project?

More milestones a project has, it is less risky for the customer. He has greater visibility into the project and sees it being ‘conquered by divide and rule.’ It is also less risky for the vendor as any lack of alignment of the deliverable with the customer’s needs is detected at the earliest point of time for correction. The down-side of having too many milestones is the overhead associated with readying the deliverable by the vendor and its testing by the customer for each of those milestones.

Obviously, it is the other side of the coin if there are too few milestones in the project. Besides, the vendor also gets paid later in the day for his efforts.

What is the golden mean?

Of course it depends on the size of the project. Well, a thumb-rule could be a vendor’s milestone for every 15% of the project efforts completed or for every 3 to 4 weeks of elapsed time whichever is earlier.

It is also not unusual to define a hierarchy of milestones in larger projects.

It is a normal practice to estimate and track other performance parameters besides the timeline for each milestone individually.

Hence, a high-level milestone or a set of milestones at lower level may be planned so as to include the all the phases of the SDLC cycle as completely as possible. Only then many performance parameters are meaningful. For instance Defects Density is meaningful for a milestone only if all the development efforts are included in that milestone.

And, finally, it is possible for the vendor to set up internal milestones not visible to the customer as part of the strategy to split it up into manageable pieces.


Do share your experiences in this regard.

Source: Image form Wiki


Read Full Post »

All projects send out status reports or progress reports to various stakeholders at some regular intervals.

This ubiquitous project artifact is often handled in a very routine manner without sufficient realization of what could be possibly achieved with it.

Here are some basic best practices:

1. It is usual to fill it up a progress report with planned activities versus completed (in part or full) in the period of review. In most cases, these activities by themselves may not be meaningful to the stakeholders. The report is much more useful to the stakeholders if milestones are set up that convey to stakeholders in their terms what is achieved at that point and the progress is tracked and reported in terms of these milestones (in addition to or instead of activities).

The milestones are thus meaningful pit-stops for various stakeholders towards achieving their business objectives. Taken together, they show a logical build-up of the project deliverables and progress to the final denouement.

For example, in the WAN project of the last post, a milestone of the kind ‘Training Infrastructure ready for cities A, B and E’ would make more ready sense to the manager of the Implementation Team (see point 8). Instead the progress report talked about the status of the WAN links to cities A, B, C, D…

Practice: Report progress with the help of meaningful milestones.

2. In a project of wider scope, there are several stakeholder classes. The progress report must cater to the interests of all these classes of stakeholders. For instance, in a SAP rollout project, it is easy to miss out the training interests. If milestones are majorly relied upon to communicate the progress, a simple mapping of the milestones to the stakeholders would reveal: a) Are there milestones to cover all classes of stakeholders? b) For a given class of stakeholders, do their milestones build up logically towards the completion?

Though any inadequacy in this regard is pointed out as a deficiency in the progress report, note that this is something to be taken care of in the project plan itself.

Practice: Cover in the progress report interests of all stakeholder classes.

3. Feel free to invent your specific format of the progress report based on the type of project, the concerns of the stakeholders and the stages of execution. One size does not fit all.

For example, consider a project where a development team is loaded with ad-hoc work-packets from a user community. Each work-packet is taken up by a programmer and completed in a few days.

If the traditional progress report format is used for this project, the report would contain perhaps one line per work-packet with its scheduled and actual dates closely matching. This is hardly insightful. In these types of projects, at any point of time, the capacity and utilization of the programming team is of more concern. So the progress report could show for the week the available resource hours and blocked resource hours and a pending queue of the work-packets.

In one such project, the work-packets were streaming in from multiple groups of users whose demands for service were often conflicting. There was no strong governance mechanism in place for arbitration on priorities. In this project, this report was used very effectively to realistically set the users’ expectations by making the backlog quite visible. Many potential conflicts of schedule were preempted much before they came to a boil.

There are times when the format of reporting the progress used in one phase of the project is not suited in another phase of the same project. For instance, when a project nears completion, it switches to the work-packet mode. Here the rush is to get as many items through work-packets covered before the code freeze. At this stage, it does not make sense to talk in terms of scheduled and actual activities.

Practice: Align the progress report closely with the project needs and concerns. It is ok to come up with custom formats and switch from one to another when the perspective changes.


Read Full Post »


8. About progress report: The weekly progress report assiduously reported the status of progress on each of those 30+ links. On the question of training plans and readiness, the manager of the Implementation Team was asked the progress report did not alert him to the change of dates. His reply was: He glanced at, but not read through the progress report. It gave out too many details. All he was concerned with was ‘When would be the minimum infrastructure required to start the training would be ready?’ That’s a simple question for which he needed a date. And that was not easily read from the progress report!

So we seem to have designed a progress report which was more suited to the management of the project execution and did not make enough sense at least to this end-user. In planning short time-frame projects the tendency is to pack it with all the necessary activities completely overlooking the need to have milestones that are meaningful to end-users. Meaningful milestones are useful in checking if the project is broken down into logically steps and are powerful aids in communicating the progress of the project execution thereafter. There is a lot to be said about effective project progress reporting which will be taken up in a subsequent post.

9. Miscellaneous activities: Often while tracking the core activities of a project, some non-core activities could get relegated to the background. And in course of time these could get critical. For instance, while commissioning the WAN, it also requires some of the current links to be surrendered back to the SP. Though not critical, if this is not done in time, the Org ends up paying charges needlessly for one more quarter.

The project is only a week away from its end. Most links except for a troublesome one where connectivity is being established for the first time, are up and running. The integration of the routers, the firewall and the servers and testing the network are planned for the week ahead. A few changes on the way were taken in the stride: The Org decided, in a simplifying move, to locate all the servers at the SP’s new data center. In some cities, the Org’s offices relocated to new end-point addresses! Some fiber links in the design had to be replaced by RF links and vice versa. For some RF links the masts had to be pushed up to greater heights.

If all ends well as hoped, it is an effort that the Project Office can well recall with pride.


Read Full Post »