|Chapter 3 - Project initiation|
We will continue with our waterfall model for a while as it serves to delineate the tasks of software creation. In the next few chapters, we will look at the steps of the waterfall, concentrating on one step at a time. To begin, we require a new step at the beginning of the waterfall to discuss project initiation.
Figure 2.1 The waterfall model with project initiation
Exactly where a project begins depends very much on the political environment. Here are a few scenarios of what might occur.
A salesperson makes a sale. She calls in a Project Manager, and together they begin to scope the work to find out what is involved.
A project is already underway, but is ill defined. The software architect extracts a design from the work already being done, then defines the direction or redirection of the project.
The chief of an organisation calls in her favourite analyst and reels off a set of requirements. The analyst is then asked when the software will be ready.
A software architect extracts the need for a common component for addition to the component library. A Project Manager is assigned to the task, and a project initiation document is created
A project, having spent a year on the back burner is suddenly required. The work is assigned to a Project Manager.
These are only five scenarios. There are many more. If you are working for a software house developing solutions for external clients, the interface between you will be well defined, and is probably a Salesperson, Account Manager and/or Project Manager. If you are developing software for use within your organization, the interface will change constantly, often on whim, and be based around individuals rather than roles.
We shall take the more traditional route, in which a project begins with it being assigned to a Project Manager.
Project management may also take place within the realm of a larger idea enclosing all of the projects. This is programme management, led by the Programme Manager, and usually takes place at a higher strata in organisational structures than project management.
A busy software development department or organisation will be managing more than one project at a time. Programme management consists of many of the same tasks as project management, but always at a higher level of abstraction from the project. It involves:
The programme is subject to many of the same problems a project is. For example, if a project in the programme slips, i.e. will not be delivered by its expected delivery date, then the programme must be adjusted to allow for it. If the project has other projects dependent upon it, they will slip too. The difficulties in managing the programme are not dissimilar to managing tasks within a project, but are often more political in nature. As a sponsor, if your project is going wrong, you need the Project Manager. If it is not going, you need the Programme Manager.
Large software projects can also be broken down into a set of smaller projects. Under such circumstances, the large project’s interdependencies and tasks are managed as a programme of work. This is the key to success on larger projects, and is the place where a Software Architect can create true technical masterpieces, or a collection of stovepipes.
It is within the realm of the programme or large project where the software architect will focus, for even when working on small projects, the architect must think at programme level for reuse, and a common look and feel for all software. It is debatable and somewhat arbitrary where the line is drawn between a software architect and a software designer. Some aspects of smaller projects, i.e. extracting common components, choosing technologies and defining the environment in which the project will work could be considered the architect’s job. Similarly, ensuring the components internal to the project work correctly and defining the user interfaces is largely a designer’s job. As long as it is borne in mind that the no-man’s land between the architect and designer includes both rather than excludes either, then we will more likely succeed.
Great amounts of work are hard to finish. Encyclopaedia are often out of date before they are finished. Maps of the world soon become inaccurate. Similarly, large projects are rarely completed. The biggest problem with large projects is that they are driven into obsolescence by the technology upon which they sit. If a map of the world can become inaccurate, what chance has a large software project with the rate at which our technological foundations change?
To conquer large projects, they must be divided into small projects. This is the logical leap many make, and it is a good start, but it is only a start. The individual smaller projects must be defined in terms of interfaces with other systems, navigation between them, and their interdependence. A programme plan must be built identifying which projects will be developed and when. Furthermore, these projects will be built upon a services framework*, and use common components, methods and tools to fulfill their shared requirements. Development of these tools and components must be built into a programme plan as mini-projects in themselves.
Project management, as defined by the Project Management Institute is:
The application of knowledge, skills, tools and techniques to a broad range of activities in order to meet the requirements of the particular project. Project management knowledge and practices are best described in terms of their component processes. These processes can be placed into five Process Groups:
and nine Knowledge Areas:
To this I shall add two more areas of concern to the typical IT project manager
And one that usually defeats the traditional project manager
Many of these activities are similar to what a software architect is doing, except the software architect is leading from a technological point of view, and integrating with existing systems, whereas a project manager is looking at it from the point of view of delivering within the time, quality and personnel constraints of the business. Balancing these needs is the function of the (often strained) relationship between a project manager and a software architect.
Suppose a client calls in a salesman or programme manager, and says, ‘I would like X.’ The salesman or programme manager might then say ‘OK, we’ll look into it.’
The process of looking into it may mean placing it on the programme plan (the one that plans the projects), or it may mean studying whether X is possible. This may be an entire project in itself entitled ‘X - A Feasibility Study’
Let’s assume the project is given the OK. The Project Manager at this point creates a Project Initiation Document, or PID. It may have another name such as Project Overview, or Project Charter. In some environments, it may comprise more than one document such as a brief introduction followed by a more rigorous statement of work.
The document should be created from a template so that all interested parties are used to the format (managing expectations) and will not have to learn a new format each time before extracting the information. Depending on the purpose of the project, it may contain:
Why the project exists, and the benefits it will bring.
Who is paying for this project, and who do they consider will provide information to aid its execution?
The area of business this project’s deliverables will work in.
An overview of what the product is expected to do.
What project success will be perceived as. This should be a list of measurable, key performance indicators.
What must be delivered and by when? For example, a prototyping phase may output an end to end prototype through a distributed or layered system, or may model an entire set of pages for the user interface before requirements are detailed. Each phase, their order and their outputs are listed.
What could prevent the project from meeting the critical success factors, and what can be done to avert those risks?
A who's who of interested and important parties.
Who will do what on this project?
Of the installed environment. What hardware is it expected to run on and what is the current software environment?
Where it will be used. What languages and cultural sensitivities must be included.
How much is the sponsor willing to spend?
What does this project depend on, and what depends on this project?
In the role assignments, you are identified as the Software Architect and presented with a copy of the PID. It contains just enough information to begin work in the next waterfall step, the gathering of requirements. If this is a business or engineering system, the process will be led by a business or systems analyst. Your contribution as software architect is to review, help identify existing software which could be used to fulfill the requirements, and identify costly requirements to the sponsor, removing them when necessary. You will also add technical requirements to the business requirements, and extract architectural requirements which must be met to deliver the business system efficiently and effectively to allow for integration with existing and future systems, and also allow for future growth.