Vertical, horizontal or mixed organization ?

There is a number of ways to organize a team and, from my point of view, there is none better or worse than the others, it simply depends on the goals, focus and priorities of the team.

What I call a vertical organization consists of a project focussed structure where the team is built up when the project starts and disbanded when the project is closed. There is as many teams as projects and first - and often exclusive - priority is delivering the project on time, cost, scope and quality.
This structure team is especially effective for critical projects and short term efforts but do not necessarily delivers long term and high quality products.

On the other hand, we can organize a team in a horizontal fashion, with specialized resources for specifics domains and not transient teams but stable in the mid term. In this way, deliverables quality increases as same people are doing very similar work for some time so they become experts in their technical and functional domain.
Horizontal organization is the most usual for operations departments and those where the stability weights more than the agility.

Is anyone better than the other? Yes, the balanced one is the best. Depending on the maturity of the company, department, systems, and professionals, depending on the business priorities, timeframe for meeting objectives and which one of the triple constraint (quality, cost and time) weights more, there is balance on vertical and horizontal functions.

There is always room for horizontal functions such as Technical Office, Quality Assurance, Program Office, Operations, Business as Usual projects, Architecture among many others, as well as some others must be driven as vertical functions, such us, first implementation of a new architecture or system, complex projects with many dependencies and so on.

Finding the balance is, as always, the challenge...

Entry or exit milestones ?

As I described in a previous post, a milestone project schedule is often requested by senior management as a way of a "helicopter view" of the project schedule, focussing the attention just in a few dates that can be tracked and reviewed easily and quickly.

Milestone is defined as a zero length event that is relevant for the project, that can be "project initiated", "product A delivered", "risk matrix distributed to stakeholders" amongst others.

A milestone can be related to the beginning (entry) or to the end (exit) of a project phase, task or activity and which one to report is part of the project management methodoly used and can change from project to project or it might well be driven by the resourcing strategy.

The end of phase, activity or task is relevant when a major deliverable is linked to it, for instance, the end of the analysis and design phase should become a milestone if a key design document will be delivered at that time. It also can be the case that one of the phases of the project is outsourced and they can invoice as soon as the products are accepted by the project manager. In such case, it makes sense to report the "analysis and design phase completed" as a milestone.

On the other hand, when, as part of the project, a number of hand overs need to happen, it is important to highlight the handing over date to allow the taking over team to plan accordingly. For instance, when a software is released and the test activity starts, that is a zero length event that will happen in a particular date and has to be tracked and published to the stakeholders as part of the project plan.

Milestone based project schedule

Project scheduling can be approached in a number of different ways depending on the granularity and detail required.

The most detailed approach consists of going down to the activity level, let us say, what as less as one person can develop in as much as a week. This schedule can not be reported as such to management and a higher level view must be prepared. It will describe project schedule in terms of phases, stating start and end dates for each relevant phase of the project. This way, we will have a good picture with regards by when resources will be needed and by when the deliverables linked to every phase will be completed.

For senior management, sometimes, it is again, too detailed as they want to track events like when the project will be completed or when the resources can be released to be utilized for other projects.

This brings us to the milestone based schedule, where only a few – up to five – dates are reported. Some examples could be: products delivered, project closed, project initiated, products ready for test and so on.