Business area steering committees
There is one business area steering committee for each business area. Each committee meets periodically to discuss projects and priorities and to refine its "plan." Business area steering committees look ahead about 12 to 18 months. Any request for a new project they generate has to be submitted to the IT steering committee, where the request is either accepted or rejected.
IT steering committee
When elephants fight, it is the grass that suffers.
The IT steering committee meets quarterly and takes an overall view across the business areas. The IT manager is the IT department's representative on this committee. Considering both business priorities and the department's commitments and constraints, this committee accepts or rejects and prioritizes project requests from the business area steering committees. Like the business area steering committees, the IT steering committee looks ahead about 12 to 18 months.
The IT manager needs to have an accurate picture of the activities of the entire department in order to commit (or not) to taking on a new project at the IT steering committee meeting. The departmental coordination team (see the following section) provides the departmental plan for this purpose. The IT manager informs the departmental coordination team of any new projects that have been committed to.
Next week there can't be any crisis. My schedule is already full.
This "team" is the key to the process. It receives new project requests, maintains a departmental plan, manages resource levels, identifies project/resource conflicts, recruits staff, manages people issues (such as appraisals), promotes good departmental communications, and so on. When a new project starts, this team identifies a business analyst/project manager (see the next section) and a prototyper from the resource pool for that manager. Also, it creates a team from the resource pool to form a solution team. This team always has a technical lead, who is the day-to-day project team leader and is the liaison with the business analyst/project manager. The project plan that the business analyst/project manager draws up must be incorporated into the overall high-level departmental plan, and any amendments during the tracking of the project must also be incorporated. Incorporating these changes is an automated process.
Business analysis/Project management
The business analysis/project management team consists of people who are specialists in particular areas of the business. A business analyst/project manager is responsible for a project from start to finish, including both technical and user-related tasks (such as user training). These teams have a lot of user interaction and might receive project and enhancement requests from the users. They manage the requirements specification and prototyping. After the solution team (described below) has built the system, the business analysis/project management team is responsible for performing acceptance testing along with the users before passing the system on for implementation.
The resource pool is a virtual pool of people; that is, it doesn't exist as a team or department and hence requires no management. It's just a pool of people that the coordination team draws from to create solution teams. Its "members" possess a wide range of experience and skills. A person in the resource pool could at any one time be multitasking across projects and wearing different hats on different projects.
Solution teams are formed to actually produce the systems. Solution team members are responsible for the design, code, unit test, and system test of a system. They work closely with the technical services team (see the next section) and have the following responsibilities:
- Ensure that the project design fits with the overall architecture
- Reuse any generally available components
- Have their deliverables reviewed and sent through a quality assurance test
The technical services team provides a wide range of technical services-mainly to the solution teams-including those listed here:
- Promote reuse by taking generally useful code from solution teams and turning it into robust components that other solution teams can benefit from
- Dictate the overall architecture that solution teams must fit their systems into
- Provide a QA function to ensure that solution teams are producing high-quality deliverables
To get maximum benefit in the Visual Basic/RAD world, users need to become much more heavily involved with projects than they have traditionally-in fact, to the extent of becoming team members. Their role is particularly important during the early stages (such as helping to develop prototypes) of the process and toward the end, at acceptance test time.
The support/help desk serves a reactive function, typically receiving problem reports as its stimulus. These reports are either dealt with within the team or passed on to a maintenance team, which fixes problems.
The maintenance team is a group of people staffed from the resource pool. Typically, a team member stays in the maintenance team for a period of about six months. The primary roles of the team are to deal with any bug fixing in live systems and to add small features requested by users. During slack periods, this team does housekeeping tasks, performs reviews for the solution teams, and the like. A dedicated maintenance team is required so that solution teams are not constantly interrupted by tactical firefighting and therefore have a better chance of sticking to project plans.
Implementation and deployment
This team implements systems in both the test and production environments.
Operations and networks
This team is responsible for the day-to-day operation of the environment, systems, and networks.
The need for consistency, coordination, and design across all projects is vital. In this case study, this framework is provided mainly by the coordination team and to a lesser extent by the IT manager and the technical services team.