Software Project Management Guide

“Become familiar with essential software project management terminology and processes.”

According to Wikipedia, “Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored, and controlled.” In this guide, software project management terminology and processes will be explored and discussed. The guide is also useful for aspiring Information Technology project managers, as the project management fundamentals are similar. Sometimes, people confuse Information Technology project management and Software Project Management. The term Information Technology project management is more comprehensive than Software Project Management. IT project management includes many types of projects, including; network upgrades, cloud computing rollouts, virtualization rollouts, business analytics and data management, hardware installations, and also overseeing projects for software development.

This guide is useful for new IT/Software Project Managers and also for general project managers.

SOFTWARE PROJECTS (DEFINITIONS)

So let’s begin with a few definitions.

Project – An endeavour that has a start and an end date. The endeavour should create a result, product, or service.
Software Project Management – It is about planning and leading software projects.
Project Manager – The project manager manages the project.
Project Sponsor – The project sponsor is the executive, and they can assign resources to the project.
Stakeholders – Stakeholders are the people or the organizations that have a direct interest in the project.

PROJECT MANAGEMENT LIFE CYCLE (DEFINITIONS)

Project management involves progression through a project lifecycle. Projects must successfully move through a sequence of activities. Project management standards such as the PMBOK divide the project life cycle into process groups. The core idea is that processes have been arranged five process groups:

Initiating is about the start of the project.
Planning refers to the planning of each phase of the project.
Executing is about creating the product or service that the stakeholders want.
Monitoring and Controlling refers to actions to: oversee the progress of the project, to identify variances from the initial plan and to take corrective actions.
Closing involves the verification of deliverables against specification.

DEVELOPMENT PROCESS MODELS (DEFINITIONS)

Organizations need to create products consistently; so they need to follow strict, well-defined, repeatable and predictable software development process. Let’s take a look at some models.

Waterfall – This model broken up into phases: requirements, analysis, design, coding, testing, and operations.
Agile – Instead of relying heavily on written documentation, daily team meetings are emphasized. Agile divides application development into modular components called iteration or sprint. Each component piece focuses on a set of requirements or features that the customer prioritizes.
Spiral – The project is broken down into sub-projects, which are then categorized according to their risk weighting.

INITIATING A SOFTWARE PROJECT

Once a project request has been received, the software project manager will have to collect all of the necessary information so as to help the organization decide on the project. The project manager will need to understand the reasons for a project’s existence. This will give the project manager the ability to know what questions need to the customer, in order to find the answers for putting together a solution.

This leads us to the business case. The purpose of a business case is to provide the leaders with the information needed so as to determine whether a project should be funded. The business case aims to “help the organization determine if they can justify the cost of the project in relation to the return on investment”. At least four things should be included in the business case: the benefits, the cost, the risk, and the results.

HIGH LEVEL REQUIREMENTS

Writing the high level requirements is one of the responsibilities of the project manager, project team, key project stakeholders and customers. The requirements will define what the project will create. It will also show the connection between the original need and the product or service that will be built. The project manager will interview the project team, the project customer, and stakeholders. The project manager and the customer should sign off on the document.

THE PROJECT CHARTER

The project charter defines the project, authorizes the project, and identifies the project manager, project sponsor, and team leaders. The project sponsor signs the project charter, which provides the project manager with the authority to start the project. The stakeholders should be provided with a copy of the charter.

PLANNING THE PROJECT

Planning results in documentation, which shows the intent of the project manager, how the project will be executed, how it will be controlled, and how it will be closed. Planning will lead to the creation of a project management plan. This plan will define the tasks to be completed and the roles and positions responsible for the work. It will also define the resources needed, the work breakdown structure and the management plans. The management plans are in the area of; scope, change, requirements, cost, schedule, quality, process, human resource, communications, risk, and procurement.

SCOPE CREEP

One of the main reasons that projects fail, has to do with a lack of careful change control. Change requests can come from many different sources, including; stakeholders, users, and project team members. Many times, the changes being requested may seem small, and therefore, the people who requested the changes may reason that the changes are probably easy to implement. However, the tiny changes often end up being difficult to implement. This problem, of changes being requested that modify the original plan, is called scope creep. The problem with changes is that time and money has to be diverted from the original plan to the changes. And many times, the change requests don’t come with extra time or money, so changes detract the necessary resources the original plan needs to succeed.

SET UP CHANGE CONTROL

In the field of IT project management, it shouldn’t be easy for individuals to incorporate changes. However, there is often great pressure to incorporate change. Some examples of the need for changes come from the need for patches, service packs, new software versions, bugs, security breaches, and stakeholder requests. The project manager needs a systematic way to figure out which of the many possible changes to implement, and which to deny. Changes need to be controlled by a system. Change control is a process that a company can use to stop others, including company leaders, from changing the deliverables without acceptable justification. The person requesting the change through a change control process has to have a good reason for requesting the change and must justify the change.

The Change Request Form – On a project, the changes requested must go through the formal change control system. If you don’t have a form for this, you’ll need to make one. The purpose of the form is to allow everyone to write his or her change request.

REQUIREMENTS GATHERING

Talking to the stakeholders is how the project manager collects the information required to create the project requirements. Conducting interviews is the process by which a project manager or requirements analyst should interact with the users, experts or stakeholders.

Software Requirements Specification Document – In order for software to be built, the behaviour of the software needs to be described, and the place to do it in is the “software requirements specification document”.
- Use Cases – They describe the interactions that the users will have with the software.
- Functional Requirements – They describe the technical details such as calculations and data manipulation.
- Non-Functional Requirements – They deals with constraints on the design such as quality, design and performance standards.

The “software requirements specification” is important because other steps such as the design, the implementation, and the testing are all based on this document.

PROJECT SCOPE STATEMENT (DEFINITION)

After the project manager has documented the business case and captured project requirements, the project manager is in a position to work on the scope. The scope statement document will document the project objectives. The project scope is the work, which refers to the deliverables that the project team will create. The scope statement is an agreement between the customer and the project team that states exactly what will be made throughout the project.

SCOPE CREEP CONTROL

In every project, there is a chance that scope creep will occur. Sometimes, people lose track of their original ideas, and come up with new ideas. People’s minds can change. Some stakeholders may go through a thought change; they may begin to make requests for features that were never part of the original plan. When you sense, that new changes are being requested with features that were never discussed at the onset of the project, you have to keep in mind that this could be scope creep, and not just a typical change request.

MAKING THE SCOPE MANAGEMENT PLAN

Though the project scope defines the work that is in scope, and the work that is out of scope, the scope management plan also includes other information relating to the scope. As part of this scope management plan, you will need to create a project scope statement, the WBS, and the WBS dictionary.

WORK BREAKDOWN STRUCTURE (WBS)

After the project scope statement is approved, the project can be planned. The project scope statement is used to create the Work Breakdown Structure or WBS. A WBS is a graphical view of what the project will create. The WBS is a breakdown of the project scope statement into component parts. Another way to understand the WBS is through the view of levels. The top most level is the project itself. At the next level below, there are the major deliverables, project phases or subprojects. Then there are more sub levels where the work is decomposed into smaller and smaller units. The lowest level is called the work package level. The work package level is used for creating estimates for time, cost, resources, and is used for scheduling. In addition to the WBS, the WBS Dictionary will also need to be created. The WBS dictionary defines the each work package in the WBS. The Work Breakdown Structure will need to be presented for approval.

SOFTWARE PROJECT MANAGEMENT – PROJECT SCHEDULE

A project schedule is simply a calendar, one that links the tasks to be done, to the resources that are available. The project manager will need three things in order to build a realistic project schedule.

Work Breakdown Structure.
An understanding of how much effort each task will take.
The availability of each resource.

Then the PM will be able to build a realistic schedule.

SOFTWARE PROJECT MANAGEMENT – ESTIMATING

ESTIMATING THE BUDGET

The length of the project tasks, the way they are sequenced, and the resources required are all factors, which help to determine the project budget. The costs need to be estimated so that the project manager knows the real cost of the project.

ESTIMATES WITH ASSUMPTIONS

The team may have to come up with an estimate, even if they do not have all of the necessary information. For this reason, assumptions can be used. An assumption allows the team to create a piece of information about something, and that information can later be replaced with the right information, once it is known. If the estimate turns out wrong, the team can point out that they did not have the right information, and were working with one or more assumptions. Assumptions warn the organization that the estimate is based on the assumption being true.

ESTIMATION CAN BE A GAME

Estimating and selling the estimate to the customer can be a bit of a game. The project manager may be tempted to give a very tight estimate, one that the customer or project sponsor would like, but then the PM ends up not having enough time to complete the project. On the other hand, the project manager may pad the estimate so as to have extra time. Using this method, if the project client does not accept the estimate, the project manager can still cut down on the estimate because there is extra padding.

TECHNIQUES OF PROJECT ESTIMATION

A critical and challenging thing in project management is being able to estimate how long a particular task will take. There are some techniques to be familiar with:

Guesstimating – There is no evidence used to arrive at these estimates, and confidence is low.
Time Boxing – Time Boxing is about concentrating a team’s effort on a critical task. It allocates a “box of time” for a task.
Top-Down Estimating – Directions from upper management as to how long the project should take.
Bottom-Up Estimating – This process separates the project into smaller components and then estimates the time of each component.
Delphi Technique – A group of subject matter experts are asked to individually provide an estimate. The results that are grouped close together are averaged.

COMMUNICATIONS MANAGEMENT PLAN

The project manager communicates with many individuals within their organization, with members of other organizations, with customers, with the public, and with others. A communications management plan must be created to help organize complex communication requirements. The communications plan defines how and when communications should occur.

COMMUNICATION WITH FUNCTIONAL MANAGERS

When communicating with functional managers, keep in mind what they are interested in. If the functional manager has employees of theirs work on your project, then they are interested in performance criteria related to the employees. However, if the functional manager is a stakeholder, in your project, then the functional manager is interested in the performance criteria related to the project. Sometimes, you will need to negotiate with the functional manager over decisions such as project staffing. To staff your project, you will need to make a meeting with every functional manager so as to discuss whom you need.

PROJECT PROCUREMENT MANAGEMENT

The term project procurement management refers to the management and acquisition of products and services from external sources. Project procurement management exists because projects need resources, products and services that are often not available in the organization.

STATEMENT OF WORK

The statement of work and the project scope statement are similar. The statement of work emphasizes the work that is being procured. The statement of work or SOW, lists the products and services that the project manager wishes to procure. Once the vendors understand what is needed, they can then bid on the project. Also, they know whether it is within their capability to deliver what it is that you need.

Vendor Solicitation – Vendor solicitation is the process through which responses from vendors are gathered.
Vendor Selection – The organization the project manager works in most likely has a procurement department. However, the project manager should be ready to take on the responsibility of vendor selection. The project manager may need to analyze vendor experience, understanding, ability, and references.

COST ESTIMATES

Cost estimates are subject to numerous uncertainties, such as: large projects, complex projects, new technologies, market trend and competitive actions. There is also the human factor, such as the psychology of the project manager. Some project managers may provide an overly optimistic cost estimate, so as to improve the chances that the project will be approved. At other times, the project managers are fearful that there may be unforeseen events that may cause the budget to increase throughout the project, and overall, that they may end up with not enough funds to complete the project. Creating a reliable cost estimate avoids these types of problems.

PROJECT COST VARIANCES

Though costs are planned, what ends up happening is that the actual costs during execution can diverge from the planned cost. For example, say you have some junior and some senior programmers working on a project. If one or more of the junior programmers leave, you may have to replace their position with whoever is available, other junior programmers or other senior programmers. In the event of the latter, that you have to place senior personnel to fill the empty junior positions, this will cost more than originally planned. Variances can be created in many ways.

PROJECT BUDGET

A project budget can be broken down into different and specific cost categories. Some examples of cost categories are, wages, software, hardware, education and so forth. The organization, which you work for, may have a copy of the cost categories that can help you to be aware of and stick to the same naming conventions. Projects will be similar from one to another; however, the categories and costs will change from project to project.

SOFTWARE PROJECT RISKS

In the software project, the risk is an event that can affect a project objective such as time, cost, scope, and quality. To deal with this, we have Risk Planning.

Time – The estimate provided may be too short to complete the project.
Cost – If the developers spend too much time, the costs will add up.
Expectations – The project manager may not manage stakeholder expectations well.
Hiring – The competitors may hire the most skilled developers.
Inexperience – The team may not know how to create the deliverables.
Scope – Stakeholders may request changes outside of the change request system.
Feasibility – Some projects are unrealistically ambitious.
Quality – The project may be completed at a reduced quality level.

SIGN-OFF

The project manager needs a comprehensive plan against which to measure project performance as the project progresses. It is important to get a sign-off from the sponsor and stakeholders in regards to the project plan.

PROJECT KICK-OFF

The kick off meeting is an official start of work on the project. Usually, the sponsor of the project will schedule a meeting, which will include the key stakeholders, the project team, and the sponsor. A good way then to create accountability is to define the roles and responsibilities in front of the sponsors. The charter and project scope should be discussed. This will ensure that stakeholders stay on track. With the charter and scope outlined, the project manager can then help keep change requests at a distance. To make everything official, the project sponsor should sign the charter, and the key stakeholders should sign the project scope.

PROJECT EXECUTION

The phase where the project work takes place is called Executing. In project management literature, “Executing” is described as separate than the “Monitoring and Controlling” group. However, in the real world, the groups work hand in hand. As work is executed, then the results are monitored to verify that they meet the quality expectations, stakeholder expectations and so on. As part of project execution, the team is assembled, the kick off meeting is held, and work on the project deliverables begins. In the meantime, different types of meetings are scheduled. These include; budget meetings, risk meetings, change control meetings, project status meetings, and so on.

MONITORING AND CONTROLLING

Monitoring and Controlling refers to processes, which make sure that the work being done is according to the project plan. If the work is not going according to plan, the project shifts back to planning so as to figure out the issues and to resolve the problems which have arisen, before going back into “Executing”. If there are changes in scope, time and cost, the monitoring and controlling process will allow you to manage these changes. Also, the Monitoring and Controlling process group involves work with the stakeholders to verify that the scope has met the stakeholder requirements.

PROGRAMMING AND LOSING CONTROL

Designing and implementing software takes most of the programmer’s time. So you would think that this would mean that the programmers would have a good grasp and control of their code. Even after all of the effort and time spent on programming, many programmers lose control of their code. It is the project manager’s responsibility to help the team adopt and stick with good programming practices such that code quality problems are kept in control.

Project managers need to be familiar with broken builds, test-driven development, and re-factoring old code.

Broken Builds – Programmers know that they need to unit test the code. Unit testing refers to the smallest testable part of an application. Even after unit testing and then delivering the build to QA, the tester states that basic functionality is broken. This happens because QA has a different testing strategy than that of the programmers. The programmers can produce higher quality code adopting test-driven development.
Test-Driven Development – In this type of development, tests are created before the code is built. The programmer creates a test case that verifies an object, and only after the test case is complete, then actually builds the object. The inputs, outputs, boundary cases, and error conditions are all defined by the time the test case is finished. The programmer will know how the object might fail, before even building the object. This programmer will catch more defects using this process.
Refactoring Old Code – Many programmers don’t like to maintain old code. Over time, many different developers patch the code, which lengthens and complicates the original design. One technique, called refactoring, can help improve efficiency and maintainability. Programming languages are expressive, and programmers can design a solution in multiple ways. Refactoring is a way to improve the design of the code without changing its behaviour. Refactoring is about modifying the code to make it easier to maintain.

IT PROJECT QUALITY MANAGEMENT

During planning, a quality management plan should be created. The plan should describe how to achieve quality, and then how to confirm the project has satisfied quality requirements.

Example: If a software application for a hospital and pharmacy is made without a quality management plan, the results can be disastrous. Assume the software’s purpose is to allow physicians to place medication orders and have the orders sent to the pharmacy. Assume a bug was created in regards to the unit of measure on a medication. Say the doctor places an order for a medication in mg, but the software interprets and fulfills the order in terms of grams. This type of bug should be caught near the beginning, not the end.

Quality is both a key principle in software project management, but also, it seems to be essential to many things in life. We hear about it all the time, from salespeople, the television, our colleagues, in education, from management, and from many other places. Someone is always telling us about his or her quality services or products. Let’s consider an example.

Example: Compare a luxury car that costs a lot but has a lot of features, and a mainstream car that costs little and has few features. Which one would you say has more quality? Many would be tempted to answer that the luxury car has more quality. The amount of features that the car has, and its price, make people inclined to say that those are the things, which contribute to quality. Now consider, if the expensive car with a lot of features, has to be brought into the garage to be fixed frequently. Certainly, then, it cannot be said that it has quality. For this reason, it is important to not rate quality only in terms of features and functionality, but to look at the other attributes such as dependability. In software development, there are systems with a lot of functionality, but a lot of defects too. Oppositely, it is possible to build system with fewer features and less functionality, but fewer defects as well.

For the software project manager, quality has two areas: the deliverable quality and the process quality that is used to make the deliverable. So it’s not just the work product, but the methods used in coming up with the work product as well.

QUALITY ASSURANCE

The goal is to meet the project specifications by the end of the project.

QUALITY CONTROL

Do not wait until the completion of the project to determine if quality exists. The process, which must be done throughout the project, is called Quality Control.

DIVIDE QUALITY TASKS TO REMOVE CONFUSION

Programmers and testers have different responsibilities. Programmers ensure that the software functions according to what they intended it to do. Testers ensure that the software functions according to what the stakeholders and users intend it to do. Testing is not always easily broken up between programmers and testers. It is the project manager’s responsibility to step in and define what tasks are for the programmer and what tasks are for the tester.

SOFTWARE PROJECT MANAGEMENT – SOFTWARE TESTING

SOFTWARE TESTING

In the field of software testing, quality has the definition of “conformance to requirements”. The software is required to behave in a certain way, and when it does not show the behaviour that is intended, then there is a defect. So the purpose of the software testers is to discover whether or not the behaviour of the software that was produced by the team, matches the requirements.

NEGOTIATE FOR TESTING TIME

Though it is essential to test the software, senior managers sometimes put pressure on the team to release the build of the software prematurely. Often, these managers don’t have a thorough understanding of software design and the software testing profession, and surmise that if the features seem to work than it is ready. The project manager must know this, communicate this, and fight to maintain the quality of the software.

INSPECTION

Inspection is a technique where the results of work are tested. The results either adhere or don’t adhere to quality standards. If they do not adhere, the work is rejected and is sent to be re-made. The inspection process is as follows. A meeting is held where a team meets to inspect a work product. From the team, a moderator is selected. The inspectors are expected to come to the meeting prepared with notes on any errors or defects they have found. Defects or errors are things, which stop the inspector from accepting the work product. So the goal Is then to remove defects, or to remove those things to which the inspectors disagree. The goal is to get them to approve the work product.

RESISTANCE TO INSPECTIONS

Knowing about inspections is important because it can be used to fight the resistance that the team will give when they are asked to implement inspections. The problem lies with the fact that many people simply do not see the connection between inspections and saving time. The truth is, inspecting work helps to prevent the team from finding the errors later on and having to fix them later when it would take more work to fix. The role of the project manager is to show that this is the case.

PREPARING THE AUTHOR

An important thing the moderator does during an inspection meeting has to do with preparing the author of the work for the inspection. Authors have a difficult time taking criticism of their work. They end up defending their work to the point that they sometimes manage to get the inspector’s to overlook problems. The objective is to have the work changed so that it can be approved. One way to achieve this is to ask the inspection team to compile the defects found into a log. Then the log is shown to the author ahead of the inspection meeting. This provides time for the author to prepare psychologically for the meeting.

DESK CHECKS

Reviews may cause some concern in that they may take too much time and effort. This is why the desk check exists. In the desk check, certain team members are given a copy of the work product, and after the review a defect report is sent back to the author. It is simply a matter of one person checking over the work of another.

WALKTHROUGH

A “walkthrough” is a review type in which the author runs the review. The author presents information, explains it, and asks for feedback. The meeting structure is less formal, and the focus is on the presentation style that will be most easily understood. Slides are commonly used to present the information about work products such as design “use cases” and “design specifications”.

CODE REVIEWS

In a code review, the team looks at and analyzes a section of code and fixes the errors. Errors are section of code that either doesn’t properly implement the requirements, or that doesn’t work as intended by the programmer, or that haven’t been designed in the best way possible. There are many lines of code and it is impossible for a team to review every line of code.

UNIT TESTING

Unit Testing is a process of running “unit tests” that check whether or not the different units in the software function correctly. Code is made up of units, such as; functions or modules. Different units perform different functions. Units of code are tested separately. Also, it takes multiple tests to verify a single unit. Tests should verify at least three aspects;

The unit performs the functions correctly.
The unit handles error conditions and unexpected values.
The unit handles boundary conditions such as zero’s and null values.

ADVANTAGE OF UNIT TESTING

Not all programmers like unit tests. But even when bugs are found on projects on a regular basis, the idea of unit testing still seems to bring about hesitation in the programmers. The problem is that programmers don’t like to do work that doesn’t end up in the final deliverable. For this reason, unit tests seem a bit like extra work that won’t be recognized. What programmers fail to realize is that doing unit testing saves time on a project. By finding the bugs up front, the bugs are then easier to fix, than they would be if they were caught much later.

CLOSING OUT A PROJECT

The project isn’t finished when the deliverables are completed. Closing out a project involves a few steps.

Acceptance/Sign-Off – The formal acceptance of the project on a document proves successful project completion.
Transfer To Operations – The product produced needs to be delivered to operations.
Team Member Release – Team members are released at the completion of specific phases or at the end of the project.
Closing Procurements – The procurement department needs to send a deliverable acceptance notice and a contract completion notice.
Administrative Closure – Collecting and organizing project documents into an archive.
Lessons Learned – Contains the problems faced, and the actions taken to fix them.
Project Close Report – Contains a history and summary of the project.

For information on software project management, visit our “Software Project Management” directory in the Articles section.

For more information on general project management, visit the Wikipedia page – Project Management – Wikipedia

Related books and resources:

“Software Project Management: A Real-World Guide to Success” by D.J. Henry – This book provides a comprehensive look at the practical aspects of managing software projects, emphasizing the challenges and best practices in the industry.

“Agile Estimating and Planning” by Mike Cohn – Focuses on the Agile methodology, offering strategies for estimating and planning that contribute to the success of software projects.

“The Mythical Man-Month: Essays on Software Engineering” by Frederick P. Brooks Jr. – A classic in the software project management field, this book discusses the complexities and challenges of software development and project management.

“Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland – Provides insights into the Scrum framework, a popular Agile project management methodology, and its applications in software development.

“Managing Successful Projects with PRINCE2” by Axelos – While not solely focused on software, this guide offers a detailed understanding of the PRINCE2 project management methodology, applicable to IT projects.

“Lean Software Development: An Agile Toolkit” by Mary and Tom Poppendieck – Introduces principles of Lean and how they can be applied effectively in software project management to improve efficiency and productivity.

“Project Management for the Unofficial Project Manager” by Kory Kogon, Suzette Blakemore, and James Wood – Offers practical advice and techniques for those new to project management or transitioning into the role, focusing on skills like communication and leadership.

“Software Project Survival Guide” by Steve McConnell – Outlines a step-by-step approach for managing software projects, focusing on how to ensure a project meets its goals within constraints.

“Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” by Jez Humble and David Farley – Discusses the principles of continuous delivery, a critical aspect of modern software project management.

“Making Things Happen: Mastering Project Management” by Scott Berkun – While not exclusively about software projects, this book offers valuable insights into project management techniques, decision-making, and leadership.

To see our Donate Page, click https://skillsgaptrainer.com/donate