Small team-based project management with a controlled iterative development model at a financial services organisation

Abstract

This paper describes a case study of an implementation of new project management and systems development methodologies at a financial services organisation. It demonstrates how A Guide to the Project Management Body of Knowledge (PMBOK Guide^® (2000 ed) and iterative development methodologies were successfully tailored to a small team-based project management environment. This intervention was undertaken in the context of a business that is heavily reliant upon new product development where time-to-market is paramount. It provides insight into how the methodologies were tailored to suit the organisation and its environment, the change management issues that were encountered and how they were addressed, and how the success of the change was measured.

Introduction

Faced with the prospect of increasing competition, including the threat of a large global business entering its market, the Company that is the subject of this paper sought to improve its new product development processes. The Company's products and services were heavily reliant upon IT, being largely information based. For example, the Company sold credit check and fraud risk information delivered via business-to-business links with its major customers. The Business had become dissatisfied with the performance of its inhouse IT operations, particularly with respect to time-to-market and productivity in relation to new product development projects. During a projects review meeting with the Executive Management Team, the PMO Manager put forward the (at the time controversial) view that the Business’ criticisms were justified and that both time-to-market and productivity performance were limited by the Company's approaches to project management and systems development. The PMO Manager proposed a solution that would involve an overhaul of the project management and systems development function and the introduction of new methodologies aimed at improving capability and therefore time-to-market and productivity. The Executive Management Team agreed to test this approach. The PMO Manager was given the authority to undertake a pilot project using the proposed methodologies and, if it could be shown that these delivered the promised benefits, to roll out the methodologies generally.

Overview of the Company

Culture and Paradigm

At the time of the implementation, the Company was involved in three major cultural transitions:

1. Structural – from mutual organisation to corporation;
2. Strategic – from online service provider to web business; and
3. Technological – from mainframe development platform to Internet development platform.

An assessment of the Company's culture and paradigm was undertaken during the implementation and the following findings were produced:

• The Company had an open culture that favoured discussion and tended to be somewhat chaotic at times.
• There was a strong loyalty to the Company expressed by the employees and management.
• Although there were manuals and reference sources available, management was left up to individuals much of the time; procedures and documentation existed but they were not managed adequately at an organisational level.
• The CEO had a strong influence over the organisation and was recognised as a “hero” type character who had managed the organisation “forever” and guided them through the many changes that they experienced – for example, the process of computerisation of the Company's business operations during the 1980s.
• Project management skills were identified as a weakness that contributed to a sense of chaos at times and it was stated that when projects near completion responsibility to do things would often fall onto someone unexpectedly.
• There was good social interaction at the Company and this was encouraged by senior management, reinforcing the open culture.
• The office was set up in an open style with little in the way of barriers between different departments; managers were situated in offices around the edges of the workstations, but these offices did not take up all of the window space; there did not appear to be a hierarchy in how the offices were situated – they appeared to be placed in the most convenient location to the team.
• The lunchroom was well set up to encourage lunches within the office, with a stove, oven, microwave, toaster, fridge and a supply of biscuits; photos of a farewell lunch were posted in a public place.
• As the organisation had its origins in a mutual organisation in a very traditional and conservative market there were elements of a closed organisation; the “underlying assumptions” (Schein, 1991) of the organisation reflected this careful, conservative approach.

Strengths and weaknesses of the culture can be summarised as follows:

• Integration – WEAK –individuals could work more co-operatively together;
• Initiative – STRONG – individuals had the freedom to initiate change and respond to issues and problems as they arose;
• Rewards – STRONG – individuals were rewarded based on organisational success;
• Trust – STRONG – management was supportive of individuals and encouraged openness and social activities;
• Communication patterns – WEAK – communication at an organisation level could be improved.

New Product Development, Project Management and the IT Department

As noted above, the Company's products and services were heavily reliant upon IT and new product development was predominantly undertaken by the IT Department according to its project management and systems development methodologies. This generally involved small to medium sized projects of between 3 and 10 people and $50K to $2M of expense. The IT Department consisted of 50 staff. The methodologies used by the IT department are described in detail below.

Project Management and Systems Development Prior to the Implementation

Waterfall Lifecycle and Assembly Line Resource Model

The Company's project management and systems development methods followed a conventional waterfall lifecycle in which resources are organised on an assembly line model. By ‘waterfall lifecycle’ is meant that the phases of a project are organised around its primary activities, e.g. requirements, design, code, test and deployment. By ‘assembly line model’ is meant structuring project resources into different functional departments so that they undertake project activities as a sequential decision making process involving handovers between functions, e.g. one department undertakes requirements activities, then hands over for another to undertake design and code activities, and yet another undertakes test and deployment activities.

By way of summary, all projects followed 12 basic steps:

1. Projects were initiated by a completing a Project Idea Form (PIF) which was then sent to the Project Office to be processed;
2. The Project Office conducted a preliminary review of the PIF by calling a meeting involving potential stakeholders and interested operational managers;
3. The Project Office assisted a business person to write a business case that would be presented to the Senior Management Team for signoff;
4. The Project Office undertook requirements analysis and documented these into a Business Requirements Specification that would be presented to the Senior Management Team for signoff;
5. The Project Office formally handed over the Business Requirements Specification to the Applications Development Group;
6. The Applications Development Group conducted an analysis of the Business Requirements Specification and documented a Logical Design Specification and then a Physical Design Specification;
7. The Applications Development Group developed the system envisaged in the Business Requirements Specification and the Logical and Physical Design Specifications;
8. The Applications Development Group formally handed over the new system to the Implementation Group;
9. The Implementation Group conducted testing of the new system;
10. The Implementation Group deployed the new system to production.

Attempts to Change

In an effort to improve time to market, the Company had made two unsuccessful attempts to introduce an iterative systems development lifecycle model. These were known to the organisation as the ‘Public Access System (PAS) Project’ and the ‘Internet Project – Phase One’. In both cases, the development team responded to initial (but by no means dramatic) failures by returning to the conventional waterfall model. In interviews, participants from these 2 projects referred to the approach that had been trialled as “an iterative approach”, but also used alternative terms interchangeably, e.g. “RAD” and “prototyping”\, which describe quite different approaches. This indicated that iterative development, and particularly the level of project management discipline that it requires, was not well understood. Other descriptions of the approaches included “cowboy” and “fancy free” indicating a level of disdain for non-traditional methodologies.

Implementation of the New Methods

Methodology

Implementation Methodology

As noted earlier, the Executive Management Team mandated an implementation approach that required the PMO Manager to first conduct a pilot project using the proposed methodologies, and only if it could be shown that these delivered the promised benefits would a general rollout of the methodologies occur. It was intended to measure the effectiveness of the proposed methodologies at 2 points, after the pilot project completed and, if everything went to plan, again once 6 – 10 projects had been undertaken as part of the general rollout. Effectiveness would be measured according to time-to-market and productivity improvement and staff satisfaction.

The implementation was used as the basis of an action research project by the authors. The first author was the PMO Manager at the Company and the second author, who supervised the first author's university study, undertook the role of external critic, providing the first author with independent advice and critique.

Project Management and Systems Development Methodology

The proposed project management and systems development methodologies were based on an application of the techniques and disciplines described in the PMBOK Guide^® and an adaptation of the Rational Unified Process (RUP). Implementation of a commercially available “off the shelf” methodology was considered inappropriate for the following reasons:

1. There was significant risk involved in such an implementation, given the Company's level of capability maturity and experience with project management disciplines; and
2. The lack of availability of an off the shelf methodology which adequately caters to the vast differences in types of projects

The PMO Manager had identified a number of specific ways in which these methodologies could be tailored to the needs of the Company. These are described in detail below.

A Controlled Iterative Lifecycle Model

Phases and Workflows

One of the flaws in conventional “waterfall” systems development processes is in presenting lifecycle process as a sequential thread of activities, from requirements analysis to design to code to test to delivery. A modern process avoids structuring lifecycle phases after the predominant activities and recognises explicitly the continuum of these activities in all project phases. (Royce, 1998, 117-118). Rather, phases should specify the state of the project, while the term “workflow” can be used to mean a thread of cohesive and mostly sequential activities, such as requirements, design, code, and so on.

There new methodology specified 4 standard phases for projects:

1. Inception – reaching an understanding of the “problem space”, exploring the “solution space”, and reaching a go/no go decision
2. Elaboration – reaching a high fidelity understanding of the “solution space”, including the plan, the requirements, the architecture and the design
3. Construction – reaching a point where an initial operational capability of the system has been developed and tested
4. Transition – achieving user self supportability

The new methodology specified 7 standard workflows for projects:

1. Management – controlling the process and ensuring wins for stakeholders
2. Environment – setting up and maintaining the development and test environments, automating the process
3. Requirements – analysing the problem and evolving the Business Requirements
4. Design – modelling the solution and evolving the architecture and Technical Design Specification
5. Development – programming, installing and integrating the components
6. Assessment – assessing the trends in process and product quality
7. Deployment – transitioning the end products to the user.

Evolutionary Increments

Another of the flaws in conventional “waterfall” systems development processes is that it is a “big bang” approach – i.e., integration and testing for the entire system occurs in one instance at the end of the project. This approach creates risk because design defects and system bugs are not discovered until the very end of the process (Royce, 1998).

This flaw is addressed in the new methodology by developing systems in small evolutionary increments. In this way, integration and testing is undertaken from an early stage in the project and defects in design and system bugs can be addressed before it is too late. Additionally, early integration and testing brings to light knowledge about the system under construction which can be accommodated in tactical changes in approach.

Application of Project Management Techniques, Disciplines and Approaches

Integrating Project Management Process Groups and RUP

PMBOK Guide^® process groups were aligned with RUP phases as illustrated in Exhibit 1: PMBOK Guide^® Process Groups and RUP Phases, below. This ensured that project management activities and systems development activities were aligned throughout the project lifecycle. RUP determined how the products of the project would be created while the project management disciplines provided a management framework for the delivery of those products.

Exhibit 1: PMBOK Guide^® Process Groups and RUP Phases

Planning and Executing Systems Analysis and Development Activities

During the Inception and Elaboration Phases of a project, systems analysis and project planning workshops were conducted to identify the major work packages and to decompose these into work breakdown structures (WBSs). The key tools used for systems analysis workshops were use case modelling and package diagrams. This practice was built into standard WBS templates for the Inception and Elaboration Phases.

The key technique used for planning workshops was collaborative decomposition of packages into tasks and the assignment of effort estimates to those tasks. The Project Manager would then capture this in a WBS for the Construction Phase of the project. In conjunction with the Business Owner and Sponsor, the Project Manager would then arrange work packages as a series of increments to be delivered as iterations according to business priorities. This process might itself go through several iterations until the project schedule was agreed. Once again this practice was built into standard WBS templates for the Construction Phase.

Controlling Systems Analysis and Development Activities

Standard status report, risk log and issues register templates were introduced, and Project managers used these in conjunction with the project schedule and weekly team meetings to control the execution of the project. The Business Owner took part in these weekly team meetings so that they were completely abreast of progress and the management of risks and issues.

Cross Functional Teams

Under the new methodology, staff retained their line of business responsibility to a particular functional group. However, staff were selected to participate in cross-functional teams which were in place for the life of the project. Roles and responsibilities in cross-functional teams are summarised in Exhibit 2: Project Team Roles and Responsibilities, below. Under this arrangement line managers had no formal role in the day-to-day running of projects, which was a dramatic change to the existing approaches.

Exhibit 2: Project Team Roles and Responsibilities

In PMBOK Guide^® (2000, 18-19) terminology, this aspect of the implementation was a transformation from a “functional” or “weak matrix” organisational system to a “strong matrix” or “projectized” organisational system.

Additional Standards and Practices

As part of the implementation, it was also necessary to address a number of informal and often chaotic aspects of the project management and systems development approaches at the Company. To this end the following standards and practices were implemented:

1. Introduction of UML as a common notation for capturing and expressing requirements and designs;
2. Introduction of standard templates for business cases, business requirements specifications, designs, and project plans, status reporting, and work requests;
3. Creation of a single project repository for all project related information – previously, information about a given project was scattered across the different departments comprising the assembly line; and
4. Definition of a formal process for requesting new projects and their prioritisation – this involved the introduction of prioritisation sessions with the senior management who represent the different functional areas of the business;

Assessment of the New Methodology Against the Old Methodology

Time to Market and Productivity Improvement

At its conclusion the pilot project was benchmarked against the old methodology. Time to market (measured as the average number of elapsed days it takes to produce 1000 lines of code) and productivity (measured as the average effort in work days it takes to produce 1000 lines of code) were both at least twice as good as the old methodology. The decision was taken to immediately proceed with the general rollout of the new methodology.

The first 8 projects undertaken as part of the general rollout of the new methodology were also benchmarked against the old methodology (see Exhibit 3 – Project Productivity, Time to Market and Cost Effectiveness). Both time to market and productivity had improved dramatically:

• Time to market improvement – projects of similar size and complexity took, on average, 22% as long to complete
• Productivity improvement – projects of similar size and complexity required, on average, 40% of the effort.

Moreover there was an improvement trend observed over several months as project staff adapted to the demands of the new methodology (see Exhibit 4: Project Productivity, Time to Market and Cost Effectiveness Trend).

Exhibit 3 – Project Productivity, Time to Market and Cost Effectiveness

Exhibit 4 – Project Productivity, Time to Market and Cost Effectiveness Trends

Staff Satisfaction with the New Methodology

Two IT Staff Satisfaction Surveys for the new methodology were conducted, one at the conclusion of the pilot project (Survey 1) and another six months later (Survey 2), revealing a sustained high level of support and enthusiasm for the new methods at the rank and file level (see Exhibit 5 – Staff Satisfaction with the New Methodology).

Exhibit 5 – Staff Satisfaction with the New Methodology

Reasons for Success

The following reasons are attributed to the success of the new methodology:

1. Optimisation of resource usage –
   • The various competencies and specialties of staff are more fully employed during the whole lifecycle; designers can start designing early, testers can start testing early, technical writers write early, and so on
   • Time is fully allocated to doing things that are on the critical path for the project rather than coordinating between different departments and department sections
   • The number of activities undertaken in parallel is maximised, thereby shortening time to market.
2. There are three areas of simplification and de-duplication
   • Simplification and de-duplication of project management activities – planning, estimating, scheduling, tracking and reporting – as these are undertaken once by a project manager rather than several times by each department and department section.
   • Simplification and de-duplication of coordination of priorities as there is one centrally managed program of works rather than several IT departments and business units with different plans, different agendas and separate meetings
   • Simplification of ad hoc progress requests, as business people need only to interface with one project manager rather than the managers and hierarchies of a number of separate departments and department sections.
3. Improved quality of important project information, in terms of accuracy and timeliness, as the information – cost/benefit, requirements, design, risk assessment, project plan and delivery dates – is kept up to date as the project progresses (almost in real time) and time is not wasted getting this information from multiple sources.
4. Reduction of opportunities for miscommunication and error as all communication takes place within a tightly knit team rather than back and forth across separate departments and sections.
5. Improved accountability as everyone assigned to a project team is accountable end to end rather than departments and department sections being accountable for one part of the process.

Change Management Issues

From the outset the implementation faced three substantial organisational change management challenges. Firstly, the implementation was not given appropriate resources and support from upper management. From a resourcing point of view, the PMO Manager was appointed to work on the implementation without assistance and without a specific budget but while still expected to perform the existing duties and responsibilities of PMO Manager of the IT Department. From a management support point of view, there was no announcement endorsing the changes and no appointment of a management steering committee to support and oversee progress.

Secondly, there was significant resistance from IT line managers and antipathy from the IT Department Manager regarding the implementation. Line managers tended to perceive the transfer of responsibility for projects from their department sections to project teams as a diminution of their power. The IT Manager appeared to be concerned that he may be seen as responsible for the failings of the existing methodology and was therefore reluctant to admit the successes of the new methodology.

Thirdly, IT staff was quite ignorant of development methodologies and the leverage that they could bring to the business in terms of time to market and productivity. This created a need to spend much time educating staff in this respect, which proved a significant burden when the implementation was so poorly resourced and supported.

The implementation approach – undertaking a pilot project using the new methodology before attempting a general rollout – helped to address these challenges. This approach had the following advantages:

1. The pilot project provided hard data concerning the efficiencies of the new methodologies and this data provided the basis of a business case for a more pervasive change to practices;
2. Risk was significantly reduced by not attempting to change the entire IT Department all at once;
3. At first only a relatively small number of people (the pilot project team) required education on the new methodology and these people then proved to be champions of the new process – support for the new methodology among the members of the pilot project team assisted to engender support among line managers and other staff;
4. It was easier to protect the pilot project from resistance than would have been the case had a wholesale change been attempted, and when the pilot project delivered with improved time to market and productivity compared to projects of similar size, resistance to the new methodologies was significantly ameliorated.

Once the new process had been benchmarked and accepted as “business as usual”, two of the key line managers who had shown significant resistance to the introduction of the new methodologies made approaches to the PMO Manager to discuss the future of their roles under the new regime. They both expressed dissatisfaction about continuing as line managers under the new arrangements. The manager of the Implementation Group made the statement “I do not want to be a glorified HR manager” and sort a new role undertaking the management of production systems and change control. The manager of the Application Development Group sort a new role as the overall Programme Manager, working closely with the PMO Manager. This proved a very satisfactory arrangement each of the parties.

Conclusion

It is often assumed that there is some law of diminishing returns, as far as the business benefits of implementing project management disciplines are concerned, the smaller the organisation and its projects. This assumption is seldom tested in practice. This implementation, however, demonstrates that it is possible to successfully tailor project management and systems development methodologies to smaller team-based project management environments. In the case of new product development, it is possible to achieve dramatic improvements in time to market and productivity, which are the cornerstones of competitiveness. Importantly, the introduction of such tailored methodologies can also have a very positive effect on staff satisfaction. It would appear, in our view, that the common assumption is a vestige of the view that project management is a necessary evil, at worst an overhead that is tolerated for compliance and risk management purposes. It is hoped that this study helps to build the contrary view, that we do project management not for these reasons but because overall it is a more effective and efficient way of working in dynamic, competitive business environments.