Software Project Management: A Guide for Service Providers

© 2016 by S. Ramanathan.

ISBN:            Hardcover              978-1-4828-7013-8

                      Softcover                978-1-4828-7012-1

                      eBook                     978-1-4828-7011-4

All rights reserved. No part of this book may be used or reproduced by any means, graphic, electronic, or mechanical, including photocopying, recording, taping or by any information storage retrieval system without the written permission of the author except in the case of brief quotations embodied in critical articles and reviews.

Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them.

Partridge India

000 800 10062 62

[email protected]

www.partridgepublishing.com/india

Contents

Preface

1 Understanding a Project

1.1 Lesson objectives

1.2 Understanding Software Project Management

1.3 What causes a software project to succeed?

1.4 Program management

1.5 Project management standards

1.6 Project management defined

2 Stages of Project Management

2.1 Lesson objectives

2.2 Stages of project management

2.3 Project management knowledge areas

3 Project Initiation

3.1 Lesson objectives

3.2 Scope management

3.3 Business case

3.4 Presentation to management

4 Project Planning

4.1 Lesson Objectives

4.2 Project Planning – Coverage

4.3 Specifying user requirements

4.4 Estimating duration

5 Time Management: Software Measurement

5.1 Learning objectives

5.2 Why measurement?

5.3 Metrics

6 Software Estimation

6.1 Learning objectives

6.2 What is estimation?

6.3 Challenges in Estimation

6.4 Can software be estimated at all?

6.5 Approaches to software estimation

6.6 Metrics for software estimation

6.7 Automation of estimation

7 Project Scheduling and Tracking

7.1 Learning objectives

7.2 Project scheduling

7.3 Assigning staff to activities

7.4 Tracking the schedule

8 Quality Management

8.1 Learning objectives

8.2 What is quality?

8.3 Quality management

8.4 Quality control

9 Risk Management

9.1 Learning objectives

9.2 Risk defined

9.3 Risk management life-cycle – Phases

10 Project Cost Management

10.1 Lesson objectives

10.2 Importance of project cost management

10.3 Project cost management processes

10.4 Project Plan

11 Project Execution

11.1 Learning objectives

11.2 Launching the project

11.3 Stakeholders of a project

12 Project Staffing

12.1 Lesson objectives

12.2 Project staffing

12.3 Project organization structure

12.4 Project Management Office (PMO)

13 Procurement Management

13.1 Lesson objectives

13.2 Growing importance of Outsourcing

13.3 Request for Proposal (RFP)

13.4 Vendor evaluation

13.5 Contract preparation

13.6 Vendor Management

14 Profile of a Project Manager

14.1 Lesson objectives

14.2 Skills required of a project manager

15 Monitoring and Controlling a Project

15.1 Learning objectives

15.2 Activities during this phase

15.3 Project status reporting

15.4 Cost control

16 Change Control and Configuration Management

16.1 Learning objectives

16.2 What is configuration management?

16.3 What is software configuration?

16.4 Challenges in software configuration management

16.5 Baseline

16.6 Functions of configuration management

16.7 Software Configuration Management (SCM) tasks

17 Release Management

17.1 Learning objectives

17.2 What is release management?

17.3 Why is release management challenging?

17.4 Release identifier

17.5 Release package

18 Expectation Management

18.1 Lesson objectives

18.2 What is expectation management?

18.3 When is expectation management important?

18.4 A technique for expectation management

18.5 Prerequisites for managing expectations

18.6 Technology – a tool in managing expectation

19 Closing a project

19.1 Lesson objectives

19.2 Steps in project closure

Annexure I

Bibliography

Preface

It was a mail from Singapore totally out of the blue; I did not recognize the sender till he introduced himself to be an old colleague. He referred to a set of slides on information security, which I had shared with my students and asked me whether these were mine. The title slide had my name. I was glad to know that several of the people preparing for the CISA examination were using those slides.

In one of the executive training programs, I was asked if I could record my entire sessions on a CD and circulate. I am sure several of my colleagues in academics would have had such experiences. Students clamour for the text books that explain the concepts in free-flowing easy-to-understand style. Many text books choose an intimidatory style in an effort to demonstrate their academic rigour and in the process fail to establish a connect with the readers – be it students or the working executives. This book intends to address this gap.

Stephen Covey says that all things are created twice – first mentally and then physically. This book was taking shape during the past fifteen years of teaching of this course. Or should I say in Maya Angelou’s words that I was bearing the agony of this untold story in me? The long class room testing has contributed to refining and perfecting the contents.

Rome was not built in day nor by a single hand. While the cover shows me as the sole author, there are several others, who directly and indirectly contributed to realizing my long-cherished dream of writing this book. First my thanks are due to my students, who by their incisive questions influenced the contents and the style of this book. This volume is a small addition to the vast literature available in this domain and I have liberally used many of the thoughts expressed by these authors. I am thankful to those authors and publishers, who generously permitted me to use some portions of their published work and some of them even wrote back encouraging me in my endeavour.

The illustrations were created by Ms. Nivedita Ramanathan and these went through several iterations to improve their communication and she patiently worked with me in evolving these. She was also helpful in laying out the text with proper numbering. In the painful effort of proof-reading to create a readable and error-free output, Mrs. Usha Vaidyanathan and Dr. Nirupama Ramanathan lent their helping hand. Mr. R.K. Ajay too chipped in to resolve any technical glitch in the word processing. All those deserve my gratitude.

My thanks are due to Partridge Publishing India, who came forward to publish this book.

I request the faculty members who teach this course, the students and the practitioners to give their comments and feedback. After all, the project management is a lot experiential and we are continuously learning!

S. Ramanathan

[email protected]

1

UNDERSTANDING A PROJECT

If you wish to converse with me, define your terms. - Voltaire

1.1 Lesson objectives

In this lesson we will learn the following:

• What is a project?

• How is a software project unique?

• Factors for the success of a software project

• What is program management?

• What are the recognized standards in the project management?

1.2 Understanding Software Project Management

If we have to understand Software Project Management, we need to understand each of the terms in it. Apparently all the three terms contained in it sound familiar, but do we understand each of them?

Could we define what software is? May sound an audacious proposition to an audience, predominantly of the software professionals. Software is the most misunderstood and hence the misused term by the software professionals. We tend to use the terms program and software synonymously and that is not correct. However we are not going define software now and will return to this fairly late in this book.

We will discuss in detail what a project is and also what the project management is in this chapter. In the manufacturing organizations, you will find two roles – Project Manager and Production Manager. How are these roles differentiated? Have you ever wondered why two such roles do not exist in a software organization and there is only a Project manager? Also try to explore these questions:

• Why do we call all the software production activities as projects?

• In software also, we use the term ‘production’. For instance we have a production environment or a production directory. We call the software development as a project whereas when it is installed in the user organizations, it is called the production environment. Does it give you any indication of the difference between a project and production?

• Now that you have an idea – vaguely though – of what a project is and how it is different from production, could you classify the following activities into these two categories?:

• The publisher of a newspaper brings out millions of copies every day, without fail, at 4 am with as much of the current news as feasible.

• You have taken the responsibility of conducting your sister’s wedding.

• An event management company, which regularly organizes weddings, has been entrusted with the conduct of the wedding.

• Every day you drive to your office through chaotic traffic for about an hour.

• A team of surgeons performs a complicated surgery.

A discussion of these questions should lead you to define the characteristics of a project.

1.2.1 So what is a project?

A project has the following characteristics:

Non-routine tasks: While in production, we repeat the same tasks again and again, a project will consist of non-routine tasks. That is why the plant erection and the pilot production are under the purview of the project management; once the production process stabilizes, it is handed over to the production manager. With the processes standardized, the tasks become repetitive. For the same reason, the software development is termed a project. If the software development process is defined, how could the tasks be non-routine? A software development activity, despite all the definitions of the processes, might encounter several uncertainties and that makes the tasks non-routine. A technical problem could stall the development of a program and may require several rounds of consultations and discussions to solve it. So is a conversion of a business process into code. On the other hand, a developed and tested program handed over to a user is expected to run repeatedly without fail. That is why it is called the production environment.

Defined objectives and deliverables: The success of a project is determined by the extent of the fulfilment of the pre-defined objectives. Associated with the objectives are a set of deliverables. These deliverables are also pre-specified and in most instances in a written form and maybe in the form of a legal contract.

Pre-determined time duration: Uncertainties in a project may well be handled if time is no constraint. The challenge arises because of the deadline fixed for the deliverables. Managing time is an important task of a project manager and a critical factor in deciding his / her success.

Involvement of several specializations: Several specialists come together in completing a project. That is why a complicated surgery could be called a project. A project manager should show the capability to coordinate between different specializations. It is no mean task to elicit compliance from the experts in different fields to achieve the project goal.

Several phases: A project goes through several phases. Phases are differentiated by the processes and the tasks. With repeated runs, a production process is made smooth and thus the day-to-day control of such processes is left to the lower level employees. But in the case of a project, the changes in the processes and the tasks across its different stages make its management challenging and requires continuous supervision by a qualified project manager.

Constrained resources: If for the fulfilment of the project objectives, your management is willing to provide an unlimited budget with no questions asked on the amount of the resources utilized and with an option to specify your own delivery date(s), you are a lucky project manager. But alas! Life is tough; your management and the client will have a definite say on the budget, the resource allocation and the deadlines. The requirement of the ability to deliver the results with the constrained resources makes this a management discipline and hence the name project management.

Size and complexity: By their very nature, projects tend to be large and complex. How are size and complexity different? Aren’t the large duration projects inherently complex? Complexity is defined by the interdependency of the components. Such an interdependency makes the planning and the allocation of resources challenging.

With the knowledge of the characteristics of a project, you may revisit the activities mentioned in 1.2 above and try to classify them as to which of them may be called projects.

So we may define a project as "a set of connected activities with a pre-specified goal and with a set of pre-specified deliverables, which need to be fulfilled with reference to the specifications within the specified time duration and the budget, optimally using the allocated resources."

A project manager thus has to manage the following factors:

• Scope: Specifications

• Quality

• Time

• Cost

• Resources

The relationship among these factors is represented by a scope triangle Fig 1.1.(Wysocki, 2010).¹

Fig. 1.1 Scope Triangle

1.2.2 Software Project Management – how is it unique?

If projects are well-defined, cutting across different fields from construction to machine building to rocket launch and if the project management has evolved as a formal discipline, what could be so special about the software projects that make their management unique? It is not our contention that software projects are totally different from the other projects, but there are some aspects exclusive to software..

What are the factors that make the software projects unique?

Product intangibility: In a software project, the final product is intangible. Does intangibility create serious challenges in its management? Compare the intermittent progress measurement in a civil construction project and a software project. Except when the foundations are being laid, the progress in a construction project is visible and thus easily measurable. The invisibility of the software product has given rise to what is popularly known as the ‘90% syndrome’²,³ in the software industry. This syndrome is the consequence of the immeasurability of the software progress. From the project management perspective, this is serious because the project manager has no way to cross-check the progress reported by a team member. Could a civil construction project manager be misled by his / her subordinates in this manner?

Limited experience: Software development is an infant science. Our experience in this domain spans a few decades⁴, while the other disciplines have amassed a great body of knowledge over hundreds or even thousands of years⁵. Based on the theories of science, engineering disciplines evolve with experience. That experience was available to software only for a very limited period – compared to civil engineering, it may be called miniscule. Software development was recognized as an engineering discipline only as late as 1968⁶. It was at that time it was recognized that software development was no art and it needed to be based on some standard tested processes⁷. We are in the process of transitioning software into an engineering discipline – with many pessimistic about such a total transformation – and till such time, the uncertainties in managing the software development process will remain.

No standard process: This is allied with the issue we raised above. Defined processes and strict compliance to the defined processes ensure the product quality. Every other engineering discipline has evolved over a period and standardized its basic processes and these processes have also been made simple enough to minimize error-proneness. The unit operations in chemical engineering have been standardized and have suffered limited changes in the last several decades. The leaf level processes like brick-laying in civil construction have been simplified and standardized so well that any unskilled labourer may learn them in a short time. These standardizations and simplifications have helped the engineers in these disciplines to undertake massive projects and complete them with ease and confidence. Such a standardization is in a very early stage in the software industry. The knowledge as to what extent the process parameters will affect the product quality has been gained by a chemical engineer over several experimentations and iterations. Such a knowledge base is unavailable to the software professionals at least as of now.

Rapid technology changes: In no other discipline, tools and technologies change at such a rapid pace and as a consequence, render the professionals redundant fast. The knowledge gained with one technology becomes useless – at least partially – when a new technology gains the popular acceptance. It might be argued that the project management is independent of technology. While this may be true in theory, there is an increasing trend in the industry to assign the project managers on the basis of technology (apart from domain) and so it has become a necessity for a project manager to be proficient in a technology. The project management is more impacted by the methodology changes. How far is the experience gained in the waterfall model projects useful in agile projects? Can the project manager take charge of an agile project without any new learning? More importantly without unlearning what (s)he has already learnt and practised? The basis of an earlier model is challenged by the subsequent evolution. The gospel truths supporting the relational approach are questioned in object-oriented design.

New and innovative projects: The type of applications to which software is put to use is changing drastically. Computers were initially confined to the scientific applications. Business became the major user soon and accounting the main application. The monopoly of number crunching soon gave room to word processing. Inventors of computers and computing would have rarely imagined that letter writing would be a major application on computers. Financial accounting and inventory control gave rise to the integrated applications. Internet changed the face of business and more e-commerce applications followed. Gaming and entertainment soon constituted our major portfolio. Now mobile apps challenge the desktop applications in every field.⁸All these dramatic changes have taken place in less than seven decades! Could we cite even a fraction of this level of changes in any other discipline?

People dependency: While there is a continuous effort in the industry to streamline and standardize the processes, software development is still far from becoming totally independent of the people developing it. Nor is it feasible to make the lowest level of the processes as simple as in the construction industry. Programming is the lowest level of the processes and even at this stage, the intellectual content of the job is of a high order. Thus one single programmer’s coding failure could lead to disastrous results in the product. While testing should be rigorous to identify such errors, it is a known fact that exhaustive testing is never feasible to ensure that no bug exists in the final delivered product. If one such error that has escaped testing were to prove disastrous, then it will be a reflection on the project manager. One of the early US spacecrafts, Mariner 1 failed disastrously because of a missing hyphen in the code!⁹ Manufacturing has perfected the assembly line production with the standardized processes and the stage wise inspections. The software industry is still far from such a regimented development approach. For want of a nail, a battle may be lost; but is it reasonable to expect the captain to check each and every nail? Ironically, the industry, with a mission to automate the processes to save labour in its customer organizations, itself is highly labour dependent!

Accommodating change: In all the other projects such as civil construction, the requests for change from the users are accepted till the design is frozen. After this stage, the project managers will decline to accept any change. In the software development life cycle too, we have a stage called freezing of the design. But that is not a stage at which the change requests are stopped, but they are formalized. By their very nature, the software projects will attract changes and such change requests will keep flowing till the product reaches the delivery stage. And that is not the end of the change requests; even after the software is implemented, the requests for change keep flowing in. This challenge is unique to the software projects. If changes were to be accepted throughout the lifecycle of the development and quite frequently in the running of the software, the design should have the flexibility to accommodate changes and at the same time the design should be robust to execute with resilience after so many changes. Flexibility and robustness are normally the characteristics that are antithetical to each other. The challenge of a software designer is to make them coexist in the product.

1.3 What causes a software project to succeed?

If the software projects are so challenging to execute, it may be worthwhile to understand, based on the industry experience, the factors that contribute to the success of a software project:

User involvement: The users play an important role in explaining the business processes, providing feedback on the submissions such as the SRS (System Requirement Specification) and the Design document and also in conducting the user acceptance tests. Many projects have suffered because of the user indifference. Particularly, the mission-critical applications such as ERP demand a high user involvement and that is why joint application development, in which the user representatives become a part of the implementation team, is recommended for such projects.

Top management commitment: Wherever the top management fails to own the projects and abdicates the responsibility totally to the IT management, it is a guaranteed prescription for failure. Responsibility of the top management does not end with the provision of the budget. Applications such as ERP and core banking might require business process changes – sometimes quite drastic - as a pre-requisite for the software implementation and such changes will normally be resisted by the middle management. This is where the top management needs to throw its weight around and exercise control. As a parody to what Georges Clemenceau¹⁰ said of war, we may say the software projects are too serious business concerns to be left to the IT managers! Such large projects will be closely overseen by a steering committee, which will have among its members the functional heads and be headed by the CEO himself / herself or by a senior management representative who has the confidence of the CEO.

Project management expertise: The role of the project manager cannot be overemphasized in this whole exercise. (S)he is the kingpin. Could one person make or mar a project – wonders Kishen (See the case study at the later part of this chapter). Many multinational organizations use their off-shore development centres (ODC) in the countries like India, the Philippines or China for the purpose of coding only and the higher end services including the project management are rendered from the US or Europe. Brykczynski (2006) cites India, Hungary, Russia, the Philippines and the Middle East – many of them emerging as important software development centres - as being weak in the project management skills and practices - all the more the reason why the service provider nations need to concentrate on this area.

Formal methodology: Software development is no more a trial and error exercise to be left to the individual excellence. With software evolving into an engineering discipline, several formal methodologies have been developed and a process focus is emphasized. More importantly, the organizations involved in the software development should ensure