A Case Study of IT Project Management

University Degree Business and Administrative studies

Informatics Research Centre

Business School

University of Reading

1. Introduction

The Campus Library has decided to integrate the library operations into an Internet-based Library Management System (ILMS). This new system should be able to provide a 24/7 (24 hours a day and 7 days a week) service as a real time learning support resource. It should be able to support routine business functions as well as the management of the information of users and resources. These are also the aims of the system.

The expected system has been mainly described as well as the business rules. PRINCE2, a structured project management method is involved for carrying out the ILMS project. This case study concerns the software development life cycle model, project initiation and project plan included in Starting up a Project (SU), Initiating a Project (IP) and Planning (PL), three processes in PRINCE2 (Figure 1). In other words, this case study focus on the preparation of the project.

Figure 1. PRINCE2 processes (where the parts in the red box is what the case study concerns)

In the next section, ILMS project will be previewed and analysed first for further discussion. Then a software development model will be chosen as the Project Approach, afterwards, the Project Initiation Document (PID) will be assembled, followed by Project Plan, a whole plan of ILMS project. Finally, a further discussion regarding PRINCE2 and Agile will take place for critically viewing the management of the project.

2. Project Overview

Internet-based Library Management System (ILMS) is an Internet-base web application with large amount of data in a database, which integrates the library operations into an online system. People can use the library services and facilities remotely, which bring much more convenience.

ILMS project is an IT project which is different from managing any other project people may have worked on. The IT projects have particular features worth discussion. The following text tries to analyse it critically.

Project introduction:

The ILMS is a normal IT project which has a medium or small scale. There is less new knowledge impact in this project as the technology about the Information Management System is mature and library daily work is well known. However, the project will still run a risk if it is not well planned.

The aim of the project is to develop a Internet-based Library Management System. The stakeholders of this project are senior manager (the Executive), the project manager, the developer. The project manager and the developer take full responsibility for the operation of the project.

Management issues:

The project manager has been given only one developer. Thus, it is absolutely impossible to carry out a team work. Because the programming is based on the knowledge of single person, the stability of the development is determined by the developer. Any trouble that the developer might meet can increase the risk of the delivery delay. Thus, a senior developer is needed here.

The project manager may not have any specific amount of budget allocated for the project. But there is still expected budget in the project. The unknown budget or the incremental applied budget from the Project Board might increase the risk of running out of expected budget.
The project manager cannot be over-evolved into the project as the project manager have only 10% of his time to work on the project.

Technology issues:

The system requirements might be clear because a library system is a common system. For a library system, the business rule and requirements might be easy to capture. Developers can easily obtain relevant information through many ways. Furthermore, the existing system (might be manual system) of library can provide much useful information for the development.
The component boundaries could be easily discovered, since the business logic in libraries is clear and the responsibilities of stakeholders are explicit.
The environments of development, testing and deployment could be easily and quickly set up, because the system is Internet-based.
The development of web applications needs less resources, no complicated hardware or software is needed. The system is also based on the existing hardware and software so that there is hardly risk of the impact of new equipment.
There will be a number of convenient development tools supporting web application.

3. System Development Model

For an IT project in PRINCE2, software development model is a kind of “Project Approach”, which should be defined at the process SU5. Project Approach is an important concept in PRINCE2 project even a small one. The Project Approach will affect the timescale and costs of the project, plus possibly its scope and quality. This should be also included in Project Initiation Document (PID) assembled at the process IP6. The aim of the following text is to choose a software development model and critically discuss it.

After a full consideration about the project constraints, the role of stakeholders, the resources and the expected delivery, The “b” Model (Figure 2) is introduced as the software development process in this project as the “b” Model is supposed to be suitable for ILMS project, which will be discussed later.

Figure 2. “b” Model

Overview:

“b” Model is a kind of iterative and incremental software development model. From the first Inception to the first Acceptance, it is called Initialisation Step. After the acceptance, an Iteration Step begins, which contains Operation, Evaluation, Inception, Analysis, Design, Production and then Acceptance again. The arrows in Figure 2 illustrate that there are positive interactions among Analysis, Design, Production and Acceptance so that the customers and developers can get effective feedbacks from each other.

Advantages:

The “b” Model suits small IT project with few developers. This is one of the main reasons why to choose “b” Model as the development model in this project.
The “b” Model has less constraints on methods, tools and personnel. Developers can use the method and development tools which they like. The manager can avoid costly methods and tools when they plan the project.
Change management in “b” Model is considered as a successful aspect. In every iteration, evaluation should be done after operation. Then, the specification of the analysis and design will be re-examined for capturing the technical changes. The next acceptance is another chance to discuss the requirement changes.
With the “b” Model, the project can be easily divided by different iterations of the model. Each iteration can be considered as a phase or milestone of the project.

The advantages of the “b” Model demonstrate that it is suitable for the project which needs the stable change control, compact processes, regular communication with customers, etc. The scale of the project can be very small such as with only one manager and one developer, meanwhile, the project can keep structured and safe. However, the “b” Model also brings some problems waiting for the manager’s attention.

Problems:

The “b” Model does neither provide the systematic software test processes nor the quality assurance. Thus, the quality of the product can be hardly guaranteed.
The “b” Model does not ...

This is a preview of the whole essay

Problems:

The “b” Model does neither provide the systematic software test processes nor the quality assurance. Thus, the quality of the product can be hardly guaranteed.
The “b” Model does not provide the explicit interface to the project management itself. So, it needs great efforts to plug the management into the model.
The “b” Model is an process based model, which means the model only focuses on the processes during the development rather than the structure of the product. Thus, the model itself does not contain any clue about how to break down the product.

Besides the problems above, for a huge project, the “b” Model might not be the best choice, since it is a light-weight development model. The “b” Model is based on process rather than the structure of the project and product, thus, it takes great efforts to tailor a product based structured management method like PRINCE2 into the model. If the project goes big, the structure of the product might run out of order. But, considering this is a medium or small project, the “b” model might be a good choice for concentration on the development and the product rather than distraction from the management activities .

For ILMS project, if PRINCE2 is used as the management method, some solution is presented as follows in order to tailor the management into the software development successfully.

Solutions:

By the end of the Initialisation Step, all project plans should be finished. All testing environments including hardware and software should be well prepared. These tasks will take most of the manager’s time.
To consider each Iteration Step as the stages in PRINCE2, the stage report should be created as soon as the stage ended. Thus, Controlling a Stage is to control the iterations.
To set up Quality Assurance at the step Acceptance. The deliverables should be modified, until the quality of the previous work measures up.
The product should be clearly broken down to structured components. Their integrality and problems should be tracked all the time.

The solutions listed above are just key points to reduce the risk of the project failure. To combine the software development model with the project management is a challenging job of the project managers. In management perspective, technology cannot help if management is disordered.

4. Project Initiation Document

At the stage IP6 in PRINCE2, a Project Initiation Document should be assembled by previous work and plans. The PID encapsulates all the information needed for the Project Board to make the decision on whether to go ahead with the project or not. It also forms a formal record of the information on which the decision was based, and can be used after the project finishes to judge how successful the project was.

4.1. Purpose:

This document has been produced to capture and record the basic information needed to correctly direct and manage the project. The PID addresses the following fundamental aspects of the project:

What is the project aiming to achieve
Why it is important to achieve the stated aims
Who will be involved in managing the project and what are their roles and responsibilities
How and When will the arrangements discussed in this PID be put into effect.

When approved by the Project Board this PID will provide the “Baseline” for the project and will become “frozen”. It will be referred to whenever a major decision is taken about the project and used at the conclusion of the project to measure whether the project was managed successfully and delivered an acceptable outcome for the sponsor/user/customer.

4.2. Background:

Approximately 389,000,000 relevant pieces of information resulting from typing keyword ‘university libraries’ in Google shows that libraries absolutely play an important role in academic activities. They have developed into a robust academic system for providing books and services of knowledge. Few people can imagine that about thirty years ago, microform was considered to be on the cutting edge of technology while now every library has a number of workstations which provide digital catalogue service. But, it still does not mean that the university libraries can survive the impact of development of high technologies, such as the Internet, database, multimedia, etc. Thus, academic libraries need more change. This change not only includes information technological revolution but also involves library future strategy.

The development of information technology which produces high efficiency of using information makes a great impact on traditional academic libraries. No one wants to go to libraries when they get enough information about what they are looking for on the Internet, on mobile phones etc. That few visitors means the libraries are facing serious financial pressures to justify their existence. Currently, a serious challenge that the university libraries are facing is how to use Information Technology to provide offline services. As some research argued, campus libraries will not vanish at all, on the contrary, these libraries will continue to serve the university and community with integration of life-long learning and consultancy services to the public and the local industry via Information Systems.

4.3. Business Case:

The Campus Library has decided to integrate the library operations into an Internet-based Library Management System (ILMS). This new system should be able to provide a 24/7 (24 hours a day and 7 days a week) service as a real time learning support resource. To develop this system, the existing library operational functions must be correctly understood and new functions may be required in order to support all kinds of services in an online fashion. ILMS should be able to support routine business functions as well as the management activities.

4.4. Project Definition Assumptions:

4.4.1. Objectives and Outcome:

Objectives:

The aim is to develop an Internet-based Library Management System which should be able to provide a 24/7 (24 hours a day and 7 days a week) service as a real time learning support resource.

The target date for having the first implementation of the web application and running is 1st July 2008.

Product Breakdown Structure:

(See separate Project Plan in Section 5.)

4.4.2. Stages:

Table 1. Stages of the Project

4.4.3. Constraints:

The project manager has been given 10 percent of his time to work on the project.
Only one developer is appointed to the project.
The existing hardware and software are allowed to be used for the project.

4.4.4. Assumptions:

There will be no new equipment available for the development.

4.5. Project Organisation:

4.5.1. Structure:

Executive: Yinshan Tang

Customer representative: Helen Denton

Supplier (Developer): Peter Monroe

Project Assurance: David Bell (appointed by the project manager. The project will take 5% of his time.)

Project Manager: Binbin Liu

4.5.2. Roles and Responsibilities:

Table 2. Roles and Responsibilities

4.6. Initial Project Plan:

(See separate Project Plan in Section 5)

4.7. Project Controls:

The progress of the project will be reported to and approved by the Project Board Executive and the customer. The developer can communicate with the customer directly for the discussion about the requirement if necessary, but it should be reported to the project manager. After System Design a meeting among main stakeholders should be held for the discussion about the system. Highlight Reports will be provided to Project Board members on a weekly basis. Responsibility for all day-to-day controls will rest with the Project Manager.

4.7.1. Exception Process

Exception reports will be produced when stages are not expected to run to plan and exceed the tolerance levels. These will be presented in such ways and at such times, as are agreed by the Project Board. The results will be incorporated in an exception plan.

4.7.2. Change Control

System requirement change is highly concerned in the change control. The requirement change must be driven by the customer. The project manger and developer can not make assumptions of changes. The project manager will report the change to the Project Board after discussing the feasibility with the developer and log the change. As long as the change is approved by the Project Board, the developer should adjust system as soon as possible.

System functional failure is also concerned. The developer will report potential failure (which means it is hard to meet a specific requirement technically) as long as he realised it. If the project manager can not solve within project tolerances, potential change will be reported to the Project Board. After discussion, customer will discuss it with the project manager.

4.7.3. Project Filing Structure

All documents will be kept within the Project Management and Project Assurance, electronically and in paper copy.

4.8. Communication Plan:

Table 3. Communication Plan

4.9. Initial Risk Log:

Table 4. Project Risk Log

4.10. Sign Off:

Project Manager’s Signature:

Customer/User’s Signature:

Project Board Executive Signature:

Date:

5. Project Plan

Project Plan is a mandatory plan that shows at a high level how and when a project’s objectives are to be achieved. It provides the Business Case with planned project costs, and identifies the management stages and other major control points. The Project Board uses it as baseline against which to monitor project progress and cost stage by stage.

The Project Plan forms part of the PID. For avoidance of redundancy, some diagrams and tables which has been used in the PID will not be showed again in the Project Plan, their addresses instead.

5.1. Plan Description:

This Project Plan contains the major products of the project, the activities and resources required. The sub-sections are Project Prerequisites, External Dependencies, Planning Assumptions, Project Plan (which includes Gant Chart, Product Breakdown Structure, Product Flow Diagrams and Product Descriptions Activity Network), Project Financial Budget and Requested/Assigned Specific Resources.

5.2. Project Prerequisites:

The developer must be clear about the whole development of the web applications including system design, coding, testing and deployment. Required technology includes UML, User Interface, at least one kind of database, script, at least one Object-Oriented programming language. The developer is also expected to understand the development model.
The requested resources of the project is crucial and urgent. The development environment has to be well set up before development. The testing environment has to be well set up before system testing.

4.7. Project Tolerances:

Time tolerance of the stages is plus/minus 2 days.
Risk tolerance will be exceeded if the analysis of risks results in a risk factor in excess of 1.5.

If these Tolerance levels are forecast to be exceeded the Project Board will be immediately notified and corrective action approved. The action has been defined in Exception Plan.

5.4. Planning Assumptions:

Customer will think over the product during the development life cycle and suggest change.
The project will have no specific budget.
The project and the development will be difficult to control.
The existing hardware and software will enough support the development.
There will be online resources provided to the developer to acquire new knowledge or technologies.

5.5. Project Plan:

Figure 3. The Gantt Chart for the Project

Table 5. The Descriptions of the Actions

Table 6. Key Milestones

Product Breakdown Structure:

Figure 4. Product Breakdown Structure

Product description:

Table 7. a Product Descriptions

Table 7. b

Table 7. c

Table 7. d

Product Flow Diagrams

Figure 5. The Project PFD

Activity Network

Figure 6. Activity Network

5.6. Project Financial Budget:

There is no any specific amount of budget allocated for the project. Any necessary budget have to be applied to the Project Board.

5.7. Requested/Assigned Specific Resources:

Table 8. Request Resources

6. Further Discussion

The text in the previous sections managed an IT project with PRINCE2. Although PRINCE2 is now a de facto standard for project management in the United Kingdom and commonly used in many fields rather than, its original purpose, IT project, it would still possible and necessary to use other project management or development methods in some projects as, the fact shows, some PRINCE2 projects also failed because of various reasons. In this part, a further discussion will be put for trying to find some different ways to manage ILMS project.

6.1. A different way to manage the project: Agile

The reason why PRINCE2 is called PRoject IN Controlled Environment is that PRINCE2 makes every effort to control the environment of the project such as the roles and responsibilities of stakeholders, products, work packages and deliverables, risks, processes and activities, etc. Although control is clearly a good thing in project management, over-control may cause lack of flexibility. Facing unexpected change, PRINCE2 may hardly work out an effective solution immediately especially a great amount of changes, because PRINCE2 assume that all changes will be included in the plan. For IT project, another problem may be found as that PRINCE2 is too big and complicated to concentrate on the software development itself. If too many this kind of problems come up in our project, maybe we shall find another method to develop the software and manage the project. According to the assumed problems, an Agile method might be suitable for the project.

Agile Modelling is a collection of values, principles, and practices for modelling software that can be applied on a software development project in an effective and light-weight manner. It has these features:

Agile deals with changes more effectively, particularly from a software engineering perspective and unlike PRINCE2, even late changes in requirements are welcomed.
Agile methods emphasize face-to-face efficient communication established at least between customers and programmers more than written documents.
Agile methods also emphasize working software as the primary measure of progress, which is frequently delivered.

Based on Agile, many methods have been produced and put into practice, such as XP, Scrum , Crystal Orange, DSDM, Adaptive Software Development, Feature-Driven Development, pragmatic programming. The best example of successful use of Agile may be the Microsoft MSF Agile Framework, which has been integrated into Visual Studio Team System. Now the framework is commonly used in the Microsoft corporation. Through the practice, what kind of projects the Agile is suitable for have following features:

Low criticality
Senior developers
Requirements change very often
Small number of developers
Culture that thrives on chaos

According to these, it is not difficult to notice that Agile may suit the ILMS project.

6.2. To jump into Agile from PRINCE2

If Agile is chosen for managing ILMS project, absolutely it should be done differently from PRINCE2. The following text is to discuss what will be done if Agile is used in the project.

In Agile, an open office and a good communication style are required since communication becomes the most important aspect of successful management. Considering this, a comfortable and warm work place with less strict rules will be set up first. It includes:

Stakeholders can have open discussions about the project and the development.
Any change that the customers/users propose is welcome.
Developer can propose technical troubles as well for seeking solutions or planning a change.

Also, the communication plan and the communication style should be changed as follows.

Communication between the developer and the customer who defined the product (might be customer representatives, product managers or system consultants) should be more convenient. Organizations may need facilities for rapid communication between stakeholders.
Frequent communication is needed, at least weekly.
The stakeholder can have informal meeting for discussion about the project and the product.
In regular meetings, the working system is expected to be showed and discussed. Working software is delivered frequently.
Both the developer and the customer are encouraged to find solutions together. This is a good way to keep the coherence and eliminate the gap between the requirements and the product.

Roles and responsibilities may also be changed.

Customer/client/user is an active role in Agile, also a team member in the project.
Developer is client facing. This is for linking technology with business directly. Clear and reasonable requirements can be selected, which benefits both sides.
Project manager lead teams in creating and responding to change with light touch leadership.

Finally, the project plan should be adjusted to Agile methods. In Agile projects, every iteration has usually 3 or 4 timeboxes. Customer puts requirements into the timeboxes, developer implements them in the fixed delivery date. But every timeboxes has maximum capacity for requirements. Customer can not put more requirements into one timebox if it is full. So, the project manager’s job here is to plan a control to the capacities of the timeboxes carefully with discussion with the developer and to detect change during the development. Last but not least, because documents will not be produced strictly during the development, a short period at the end of the project is needed for documentation.

Finally, the following diagram illustrates summarily what should be replaced in PRINCE2, if Agile methods are considered as the development and management method instead of PRINCE2.

Figure 7. Comparison between Agile and PRINCE2 (LitheBlog, 2007)

Bibliography:

Bentley, C (2005). Practical PRINCE2. Norwich, TSO (The Stationery Office). ISBN 0-117-03544-0.
Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5.
LitheBlog: Exploring Lean and Agile (16/09/2007). Access date: 30/05/2008
http://lithespeed.blogspot.com/2007/09/agile-project-management-role-of.html
OGC (2005). Managing successful projects with PRINCE2. 4th edition. London, TSO (The Stationery Office). ISBN 0-113-30946-5.

A Case Study of IT Project Management

This is a preview of the whole essay

Document Details

Related Essays

Remington Peckinpaw Davis Project Management Case Study

ericsson case: project management team and roles

Strategic Program Management Case Study.

Purchasing & Supply Management - Case study on marathon oil.