Software Project Management

This post isĀ  related in some ways related with Application Lifecycle Management (APL), DevOps and Continous integration (CI).

Software Development Model

Software development models or software development lifecycle models. You can find a list on this post.

The most popular are waterfall and agile.

Process Improvement Model

Process improvement frameworks can also be applied for software. You can read more about them on this post.

An example of process improvment model is software capability maturity model (SW-CMM). You can read more about it on this post.

Steps on Software Project Management


  1. Planning
  2. Development Methodology
  3. Requirement Specification
  4. Design
  5. Implementation
  6. Testing
  7. Follow-up
  8. Transition to maintenance


Planning is vital to achieve objectives. All activities within a plan should be focused on achieving the desired objective.

Planning must take into account:

  • Time constraints
  • Budget constraints
  • Resources constraints

All steps since the beginning of the project must be planned. However, plan may start drafted and be updated and more detailed as the project progress. For example, it is impossible to define how long will a project take when we are not having the estimations. But the initial planning can cover the initial steps like, for example, consider all the previous steps until estimations are achieved.

Also, estimations can be provided in different level of details. For example, we can start with high-level estimation, and then update them with low-level estimations. This will imply an update in the plan.

Deviation and progress must be taking into account.

Deviation and change of scope are common in project development. We must assume it happens sometimes rather than denying it, and consider a very human limitation being unable to predict the future. The important thing is to register this deviation and change of scope, and re-plan and inform all stakeholder about the consequences on a timely manner.

Development Model

Pick a SDLC model and a process improvement framework.

Requirement Specification

When you start a software development, you need at least a hint of what you are expecting to get. This is what I call requirement specification. Depending on the methodology used, it may have a different name like business requirements, definition or specifications.

These goals must be defined by the product owners.

The definition will be more or less detailed, and more formally or informally, depending on the methodology.

Level of detail of requirements depend on developer expertise, connection with the product owners or understanding of the product or industry.

Waterfall methodology require more level of detail, because the idea is not to repeat iterations, so you must ensure that before starting implementation all definitions and scenarios are clear.

Definitions are sometimes used as a contract. This is specially important when we work in a functionality achievement approach (rather than a set of developers assigned permanently to a project), and also when outsourcing development.

It is a good practice to define test scripts during definition. In this way, the expected outcome is clear for the developer. In addition, it adds a measurable and objective way to assess whether the development objective was achieved, as a true-false statement (“Is the outcome of the process what has been defined in test scripts?” The only possible answers, if the test scripts are well defined, is yes or no).

Remember to define not only the positive cases where the process run smoothly, but also the possible errors. It is common to have to spend more time analyzing the error scenarios than the correct scenarios, as the error ones are more complex situations.


You may have a design phase once or many times during the project lifecycle, depending on the methodology.

Some technical decisions that were avoid during requirement specification are taken during the design phase.

Low-level definitions are not usually delivered until this phase.


You may have one or many development cycles, depending on development methodology applied.

You need to set a software development environment, what is expanded in this post.

This can be considered the most technical challenging part of the software creation process. The rest of the steps require are more balanced with soft skills.


There are different types of test. This one goes in a top-down approach:

  1. User Acceptance Test
  2. Functional
  3. End-to-end
  4. Integration
  5. Unit

Tests can be:

  • Manual: requires human interaction
  • Automatic: do not require human interaction

Depending on the automatic testing tool, a team member may need to program or record the tests that must be done as a previous manual step before achieving automatic tests. It may imply also some manual maintenance. This is the case of tools like GreenPepper.

An alternative is that testing tool detects possible bugs automatically. This is the case of Sonar Qube.

Identified bugs or faults must be registered in an software tracking system. You can find a list of popular software tracking systems on this post.

Different environments are used. The most usual is to have these environments:

  1. Development
  2. Test
  3. Production

There may be one or serveral test environment. They receive names like UAT, QUA, Preprod, etc. Each test environment may have a different version. Usually they are progressive, so the latter environments are closer to production environment.


Software projects require a regular follow-up.

It is very important to check that all deadlines are met. In case they are not met, it must be informed to stakeholders as soon as possible. Some of the stakeholders may provide solutions (for example, provide additional resources, reduce project scope, etc.).

Software tracking system should be accurately informed and always updated. This means the commitment of the whole team, who must understand the negative consequences of not being strict when using it.

Daily stand-ups is a method proposed by agile methodologies to ease communication in an informal way.

Transition to maintenance

At the end of each cycle, project team must complete a transition process to ensure that the delivered product can be maintained in a correct way.

Frequently project and maintenance teams are composed by different people, so in this case it is even more important that this transition is properly done.

Some of the taks that must be done during transition to maintentace:

  • Inform users about new functionalities
  • Train maintenance team about the new functionalities and possible issues
  • Update monitoring and alert tools, if required

Special Scenarios of Project Management

Free and open source software (FOSS) require particular aspects to be taken into account.

You can read more about how to handle FOSS project management on this post.

You might also be interested in…

Leave a Reply

Your email address will not be published. Required fields are marked *