Project structure and approach

The programme that took America from President John F. Kennedy’s commitment in 1961 to putting a man on the moon within the decade, and achieving that in July 1969, was an astounding achievement.  Many decisions had to be made, not only on the technical aspects of how to do it, but also about what would be the best way to organise the NASA Apollo programme to give it the best chance of success.  There are several basic designs of project (and programme) organisation.  Which would be the right one for Apollo?

The functional project structure

There are three basic ways to organise a project – its structure.  Traditionally projects were organised in the same way as operations, based on a functional structure where on larger projects work had to be navigated across clear department boundaries.  This often led to lots of conflict, delays, overspending and a sub-optimal output.

The project-based structure

A project-based structure involves assembling an organisation that is focussed solely on the project.  This may produce a better output but can inhibit the wider organisation from learning new knowledge from the project experience. New knowledge acquired by the Project B tram may not be shared among the other project teams.

The matrix project structure

The matrix structure tries to balance these two styles.  Staff remain in their home departments and are deployed on to projects as required.  It is complex to manage, but means that technical and project expertise grows in the functions.

Project approaches: waterfall and agile

When it comes to project approach, the traditional way is often called the waterfall, a predictive approach where requirements are frozen at the start and work is expected to flow predictably through stages until the output is delivered.  In many projects a more emergent approach is necessary because everything cannot be defined at the beginning.  Thus a flexible and adaptive approach is required, where we freeze what we can and tie down the rest as we go.  Even this is too constraining for fast-paced software development, and the agile approach was devised to allow a team to move rapidly as a customer’s real needs and priorities emerge.  Agile is now used in lots of other types of project. 

In large, complicated projects systems integration is needed to combine all the elements of the output and ensure that they work together properly. It is possible for a project to involve different approaches at different points. For eample, agile may be used to develop a new corporate IT system, but waterfall is employed for the work to roll in out across the organisation.

Main source

Davies, A. (2017). Projects – a very short introduction. Oxford, UK: Oxford University Press.