Assuming that everything and everybody outside a project will hold its breath between inception and completion is arguably a risky bet; more probably the path from requirements to deployment is bound to be affected by changes in business or technical contexts, not to speak about what may happen within the project itself. Such hazards are compounded by scale, as large undertakings entails the collaboration of several teams during significant periods of time. Hence the need of milestones, where expectations are matched to commitments.

Milestones are where expectations meet commitments


Project sequencing can be defined equivalently by milestones or by intervals in between (phases, stages, etc.) The former perspective is to be preferred as it is less prone to methodological connotations and it can be based upon clear and unambiguous rationale, internal or external to project.

Internal justifications deal with project objectives, resources and achievements, e.g:

  • Scale: milestones are set by thresholds, measured for instance by function points.
  • Time-boxing: milestones are set by periods, for instance every week.
  • Test driven: milestones are set by quality thresholds, measured for instance by number of detected errors, performances, etc.

External justifications deal with contexts and associated risks. Milestones are introduced when confirmation or consolidation are required or when adjustments are to be expected.

  • Business context: objectives being set by market opportunities, change is the rule more than the exception and therefore should be built into project management. Yet, requirements cannot be managed on a continuous basis and commitments must be sequenced by milestones.
  • Technical contexts: technologies and innovations are not always predictable, and when they are, options may be altered by organizational mutations. Dependencies between functional and non functional requirements should therefore be identified upfront and associated with milestones.

While internal justifications may be set along methodological preferences and dealt with at project level, that is not the case for external ones, which are clearly set by project objectives and contexts. As such they are meant to be negotiated between project and stakeholders, which do not necessarily share the same methodological creeds, if any. Hence the need of milestones to manage expectations and commitments along time.

Milestones and Architecture Driven System Modeling

Milestones can be set specifically for each project, along predefined project life-cycles, or selected from standard development patterns. The first option is not of much help and the second one is based on the one-fits-all bureaucratic fallacy, but the third one opens the way to proper design and assessment of engineering processes.

As should be expected with architecture driven system modeling, milestones are to be based upon architectural concerns. Starting with objectives, requirements can be regrouped in four categories:

  • Business requirements are defined by stakeholders in charge of business units, business domains, or support units. They are set relative to enterprise architecture.
  • Functional requirements are defined by organizational units managing the resources. They describe the part played by symbolic systems in support of business requirements.
  • Quality of Service requirements describe how systems are to be used independently of business contents.
  • Technical requirements describe how systems are to be implemented independently users’ experience.
Requirements and Architectures

Depending on organizations and methods that classification may be refined further but, as it is, it provides a backbone anchoring processes to architecture layers:

  • With regard to business processes, milestones can be defined for (1) business requirements regarding domains ans activities, (2) roles played by systems within the organization and, (3) quality of service.
  • With regard to engineering (aka development) processes, milestones can be defined for (1) project requirements, (2) system functionalities and, (3) software architecture.
  • With regard to services management processes,  milestones can be defined for (1) locations, (2) services to be supported and, (3) releases deployments.
Milestones are used to anchor process to architecture layers.

On that basis, engineering milestones may include all levels, from requirements to implementation, according to functional footprint:

  • Local execution units (entry points)
  • Shared execution units (applications).
  • Persistency units (aka entities).
  • Midleware and Services
Milestones are considered depending on footprint/

Alternatively, they may also be limited:

  • Integration: due to mutations in organizational or technical contexts architectures are to be modified independently of business requirements.
  • Migrations: the impact of organizational or technical mutations is confined to implementations and doesn’t affect architectures or business requirements.

It must be noted that, while integration and migration patterns will usually modify users’ experience, corresponding milestones should not  be confused with Quality of Service requirements.

Milestones, Waterfalls, and Agility

Due to a frequent misunderstanding, milestones are often dumped together with waterfalls when compared to agile approaches to software development. That is very unfortunate as milestones may provide sound ground and firm footing to agility.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.