Managing Your First Software Project

The first in a series to help you manage your first software project, written by a thirty-year project management veteran.

You are an up-and-coming superstar in your company and thus, you’ve been assigned to lead your first software project. Maybe, it is upgrading a financial system package, building a new website, or selecting and implementing a new ERP system. It could be almost anything. While you are a great manager and really know the business, you don’t know how to install or build computer systems. You will obviously have some help, but if you are going to manage the project you need to understand what is going on.

I’ve been helping managers like you run large software projects for nearly thirty years. In this and a series of related posts, I’ll be sharing my experience and giving you the background you’ll need to manage your own project. This post will be an initial overview and starting point advice. I’ll be adding links to other posts covering specific aspects of managing projects.

People, Process and Technology

All projects have a people and process component and in this modern age 99% of them also have a technology component. Your primary role will be to manage and coordinate all three of these components to make the project a success.


What do I mean by “People”? I mean getting the people in the company to support your project or to at least use the software. Until the androids take over, this will also be the hardest part of the project. People are set in their ways and have their own agendas which may not include the extra work your project will cause.

Consultants use the term “Change Management” to encompass the people aspects of a project. This usually just boils down to training and communication in most projects. In more complex projects this could include designing new positions, adjusting bonus incentives, layoffs or staffing new offices. Whole books have been written on Change Management and I’ll provide more details in other posts, but for this overview just remember that you can build the best software yet it is worthless if people don’t use it. Let’s use COVID 19 as an example. A revolutionary vaccine with the capability to save millions of lives was developed in record time. Yet, a huge level of effort  had to be expended to convince people to take it. The vaccine was developed in a year, but I’m writing this three years after the vaccine was developed and people are still debating it.


What does “Process” entail? This refers to the business aspects of the project, and more simply the business process in which the project is changing. For example, the business process scope could be: financial reporting, customer service, distribution, warranties, etc. Your project will be improving this process in some way and will ultimately increase the business’ profit. In the simplest projects, this involves defining the scope and business case.

An example of scope would be domestic distribution of customer orders in North America, but not international shipments. This is the area where your project will focus, including a rationale for why you are excluding certain processes. Maybe North American shipments are handled in SAP, while international shipments are handled in a custom system developed by your freight forwarder. If the biggest opportunity lies in North America, it makes sense to simplify by only working on SAP for now. While the international shipments can be addressed in the future by another project.

The business case is simply what benefits will the business owners get for spending the money on the project. How much will the project cost and how much will profit increase? There are projects, like regulatory compliance, which don’t have a direct impact on profits other than avoiding fines or keeping the owner out of prison, in which case the business case is: to keep the owner out of prison.

In complex process efforts, the business processes or procedures are being redesigned. The way people will do their work is changing. This involves detailed process modeling, documenting new procedures and redesigning performance metrics.


What is meant by “Technology”? In general, it is the thing being built or modified. This is most often software, but could also be a new COVID-19 vaccine. However, I’ll focus on projects building or modifying software since I don’t know anything about inventing vaccines.

The computer systems will be referred to as “IT”, “systems”, “software” or “hardware”. You will most likely have help from your information technology (IT) department with much of this work. But you don’t want to be blindly leading the technology aspects, entirely dependent on the IT group. You need a basic understanding of how software is developed and implemented, especially so you understand what the People and Process aspects of the project need to do to support the Technology work.

I cannot emphasize enough that this is the most important component of the project, this is where value is being added. The People and Process components are the supporting players. Therefore, an efficient project is going to focus on making the software developers as productive as possible. If developers don’t have fingers on keyboards then value isn’t being created. If the new computer system doesn’t work, then all the process changes and training are for naught.

When IT projects go awry a lot of blame is usually leveled at the developers for sloppy coding or being too slow. This is rarely the case. In most cases it is a systemic issue about how the project was managed. System requirements were late or sloppy. Training was poor or non-existent. Testing was poorly designed. The list goes on, but it boils down to the project manager (e.g. you) didn’t do a good job of feeding the developers what they needed and didn’t manage the supporting People and Process components properly.

Software Development Life Cycle

All software projects go through the same basic process: Plan, Analyze, Design, Build, Test, Deploy. There are variations depending on whether you are installing existing software or doing custom development, but the basic process is consistent. You will only be performing the Plan Phase once but you’ll be repeating the other phases for each release. I’ll create a post on the details of each of these phases but here is a summary.


The Plan Phase is pretty obvious, you are planning the project and making high-level directional decisions before performing detailed analysis. Some of the key decisions are:

  • What is the high-level business case? Roughly how much will it cost and will the benefits justify the cost.
  • What are the high-level software requirements? A list of what the software needs to do. Identify any key interfaces with existing systems.
  • Should we make or buy? Meaning, do you buy software off the shelf or code it from scratch. In many projects you may have a combination of both.
  • Do we need external help? Determine if you need a consultant to help with the Plan Phase. You may need a strategy consultant like McKinsey to help develop the high-level business case. You may need a project management expert to help with the make vs. buy decision? If you are buying an off-the-shelf software you will probably need some professional guidance on installing the software.
  • What is the high-level timeline? Logically group functionality into releases and determine how long will it take to complete each release.
  • Should we proceed with the Analyze Phase? Determine who needs to be dedicated to the team to perform detailed analysis. Determine how much the Analyze Phase will cost and how long it will take. Get approval to spend the money and staff the team.


The Analyze Phase for the first release on large projects can take several months, especially if you have to select the off-the-shelf software you want to purchase. For small projects doing custom coding or using existing software this phase can be only a couple of weeks. The key deliverables for the Analyze Phase are:

  • Detailed current state review. Review how things are currently done, so that you can identify: detailed software requirements, required process changes, improvement metrics and who will be impacted.
  • Future process. Design the future improved process as this will drive software requirements.
  • Detailed software requirements for the first release. This will be everything the developers will need to know to design and build the software. Detailed requirements can be documented just-in-time for later releases.
  • Finalized business case. Develop final cost and benefit estimates that will be used to measure the success of the project.
  • Software selection. If using off-the-shelf software, the software is selected and purchased at this point.


The Design Phase is focused on software design. All the business and process design work has already been done in the Analyze Phase. The phase is extremely short for small projects making changes to existing software. Software development is so quick these days, it is often easier to build something and review it for input rather than spending a ton of time designing it. If you are building from scratch on a large project the main deliverables are:

  • Software install. If using new off-the-shelf software, the software vendor and perhaps a supporting consultant will join the project now that contracts have been signed. They will have a series of questions that will need to be answered to perform the initial install of the software so that detailed configuration can start.
  • Technical design. For custom builds, the technical team will be designing the software components like databases, user interfaces and system interfaces.


The Build Phase is the fun phase. The team actually starts building custom software or configuring off-the-shelf software. The Agile software methodology is applied in this phase to build the software quickly and efficiently. You should assume you will be using the Agile approach, as this is the de facto approach for all modern software projects. As manager of the project, you should expect to see working software coming out of you systems development team daily with formal demos every two weeks.


The Test Phase should overlap with the Build Phase and wrap up with formal user acceptance testing. As soon as something is built it should be tested by the person who wrote the requirement. So this level of testing should be an ongoing real-time process within the team. Once the build is complete for the release, you should hold formal user acceptance tests with the end users to make sure all the requirements were understood properly. Once end users can get their hands on the software they will always come up with new requirements or bugs. It will be your job to decide whether these new requirements or bugs must be addressed for the first release or can be pushed to a later release.


The Deploy Phase covers all the activities required to put the software into use. Key deliverables are:

  • User Training. Train the users on how to use the new software and any new processes.
  • Software Migration. The new code or new software has been built and tested in non-production environments only accessible by the team. Now the new build needs to be moved into a training environment to support training and then into the production environment where it will be used.
  • Communication. Everyone impacted by the new software needs to understand the changes, how they will be impacted and any actions they have to take.

If your project has multiple releases, you now repeat the Analyze, Design, Build, Test and Deploy phases for the next release. To be efficient, phases for each release should overlap. Business Analysts should start analysis for release two during the Design Phase of release one. Developers should be building release two during the Test Phase of release one.

Software Project Roles

Hundreds of people can work on a large software project, and the various responsibilities can be numerous but they basically boil down to a few key roles. Here is an overview of these key roles:

  • Product Owner – This is your role. It can go by different names like program manager, VP/Director of X Project but it basically means that you are the person upper management is holding responsible for the success of the project. You will be responsible for prioritizing the software functionality.
  • Sponsor – This is the manager whose budget is paying for the project. Since they are paying for the project they obviously have the final say on all major decisions. They also have to be kept informed so they are confident their money is being spent well.
  • Steering Committee Member – These are managers of the departments which will be severely impacted by the project. They will have to be convinced to lend resources for the project, either to help the team or to be trained. They will need to be consulted on key project decisions that impact their departments.
  • Project Manager – This is a person experienced at running software projects, which will help you by running the day-to-day aspects of the project. On Agile projects, this role can be called a scrum master. On small projects, the same person can fill both the product owner and project manager roles.
  • IT Architect – This is the IT person who will guide the team on key project technical decisions and designs. They will make decisions like: what language to code in, how to structure the database, etc. On large projects there may be several different types of architects specializing in different technologies.
  • Business Analyst – This is the person documenting the processes, business case and requirements. They ensure the developers have the information they need to build great software. In many cases, the business analyst will also be testing the initial build and creating training.
  • Developers – These are the people actually coding the software or configuring the off-the-shelf software. These are the people that make the magic happen, and all the roles above are basically supporting roles so the developers can create great software.

Software Environments

A key concept that managers struggle with on their first software project are the many software environments. Think of the environments as different snapshots of the software in time. Different companies use different names but they typically all use four environments for the same functions:

  • Development – This is where the developers do their coding or configuration work. This is chaos and unstable. There can be dozens of developers making changes simultaneously.
  • Testing – There will be a formal process to periodically move changes from the development environment to the testing environment. The changes will be moved for a specific release so that it can be tested. This environment will be much more stable, and should reflect the changes going into the next release.
  • QA/Training – This can be one or two environments, that serve several purposes. In between releases it is a duplicate of the production environment with either a full copy of data or a near-full copy of data. It is used to investigate production bugs. Just prior to a release, this environment is updated with the new code that has passed testing and is setup with data to be used for training.
  • Production – This is where the work is done. All end users must be trained and ready before release changes are moved to this environment.

Some key environment concepts you need to understand as manager of the project are:

  • Setting up these environments is a lot of work. If you are working on existing software, these environments will already be setup. But if you are building/installing new software then these environments need to be created.
  • Access to these environments is controlled separately. The project team works in the Development, Testing and QA/Training environments. Separate usernames and logins will need to be created for each environment. Developers should not have access to Production. All changes should flow from Development to Testing to QA/Training and then Production with checks and re-checks occurring along the way.
  • Migrating changes between environments is a lot of work and easy to mess up. Migrating the changes three times is practice for IT to make sure they can do so quickly and smoothly. In fact, IT should be automating the process of migrating the changes as much as possible so the automated process is perfect for the move to production. After each migration, a test has to be run to confirm the changes were migrated to the environment correctly.


I’ve given you an overview of the key subject areas for managing a software project. Of course, we’ve just scratched the surface. I’ll be adding more posts on these various subjects to flush out some of the details. Remember your role will be representing the business and ensuring the project goals are achieved. If you assemble a good team, you’ll have the help you need to execute the details correctly. But hopefully I’ve armed you with a enough so you can speak a common language with your expert teammates.

Additional Reference

Project Charter Guide and Free Templates

Save Time with Free Excel Software Decision Matrix

Please Subscribe to the Project Management Blog

You will receive a weekly email with blog updates. I try to write two blog posts a week.
Your email will only be used for blog updates.

    Leave a Comment

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