Project Management in Software Development: Key Questions Answered

You’re venturing into software development. You have a future-proof idea, detailed requirements, just enough technical expertise, and a skilled team. You’re only lacking an expert project manager. With said givens, what are the odds of you completing the project?

The sad truth is the chances for success are not that high. Various studies suggest that the primary causes for failures in software development are mostly bound to poor project management.

Common mistakes in managing software development projects that are causing those to fail are changing project objectives, inadequate communication, poor change management, inaccurate cost estimates, unidentified risks, and others.

So, to make sure your project does not spin out of control, you have to make healthy project management a priority. Below, we share our expertise in , answering acute questions about managing software development projects.

How important is project management for software development project success?

Shortly, very.

Software development projects are typically very complex. For a project to be considered a success, it must deliver on the requirements and guarantee high execution quality, while being completed on time and within budget. And that is what a project manager is responsible for.

The benefits of hiring dedicated talent for managing software development projects, thus, span:

• Reduced risks

  A project manager is responsible for effective risk management. At the very start of a project, they map out, document, and prioritize potential risks, as well as design a risk response strategy.

  
  

Four common ways to respond to risks span:

• Avoid: eliminate or forego a threat
• Mitigate: reduce the likelihood or impact of a threat
• Transfer: assign or move a threat to a third party
• Accept: acknowledge a threat and choose not to resolve, transfer or mitigate it.

To come up with an appropriate risk response strategy, a project manager may set up brainstorming sessions with the team, resort to storyboarding, or interview individuals from all parts of operations. With the risk management strategy on hand, it becomes easier for the project team to foresee risks and timely prevent them.

• Better control over project costs

  Cost overruns are common in managing software development projects. As they not only impact margins but also hinder the ability to execute the project, an experienced PM comes up with an optimal approach to cost management.

  They estimate, budget, and control costs throughout the project lifecycle, aiming to keep the expenditures within the approved room. Healthy cost management also helps set expectations for stakeholders, control scope creep, increase project ROI, and monitor long-term cost trends.

• Optimal utilization of resources

  Healthy project management in software development helps make sure all project resources spanning people, their skills, time, tools, equipment, and services are coordinated and utilized efficiently.

  
  

  During the , a PM estimates allocate, and plans the needed resources, as well as distributes them according to priorities. During development, the PM tracks resource utilization and removes any bottlenecks that may hinder project completion.

• Better control over the project scope

  A common issue in managing software development projects, scope creep is better to be avoided. Uncontrolled changes influence project schedule, budget, costs, and resource allocation, as well as compromise the delivery of milestones.

  
  

  Approaching project management in software development, a PM sets up a change request procedure and makes sure it is followed for each new requirement. The aim is to avoid uncontrolled scope creep and make sure the project is delivered on time and within budget. Once the new activity is approved and added to the scope, the project timeline and budget baselines are updated accordingly.

What is project management in software development?

Project management in software development is the art of planning, scheduling, and tracking project activities given the available resources and constraints.

As said above, software development projects are pretty complex and include multiple stages. A project manager plans out and oversees project execution throughout these stages.

According to the , there are five key stages in a software development life cycle from a PM’s point of view.

• Project conception

  The key goal of the project conception stage is to determine core project objectives, define business needs, and draft the statement of work. The latter should include, above all, the requirements for the future solution and a project delivery schedule. Project conception typically requires close collaboration between all project stakeholders, with a business analyst and a project manager taking a lead.

• Project planning

  The project planning stage is a cooperative effort of a project manager and a project team. The project team designs a solution’s technical architecture and comes up with its look and feel. A PM, in turn, devises a project plan, crafts a work breakdown structure, and prepares a project schedule. The end goal of the stage is to get a clear understanding of the project scope and set the basis for project performance monitoring and control.

  
  

  At this stage, a PM also sets up communication and progress tracking tools, as well as plans for future deployments, defining acceptance criteria.

• Project launch and execution

  While a project team is engaged in engineering and testing the future solution, a project manager monitors the team’s performance, removes bottlenecks that may hinder project work, facilitates communication between the team members and project stakeholders, documents project progress, tracks risk triggers, and reports to the client or senior management.

• Project Acceptance

  At the project acceptance stage, the solution or a set of deliverables is rolled out to a staging environment, where it’s beta tested. The development team provides the necessary foxes if needed. The PM makes sure the solution is delivered fully and on time, as well as guarantees the delivered software meets the agreed acceptance criteria. Another part of project management in software development at the project acceptance stage deals with preparing user guides, installation instructions, and other project documentation.

• Project completion

  Once a project is completed, a project manager holds a retrospective review, where they assess and document the ups and downs of the entire project. They also ensure the full scope of deliverables is handed over to the client/product owner, including all source code, software documentation, development environment, and more.

  
  

  These essential stages can follow each other linearly or allow for more overlapping — depending on the chosen approach to managing software development projects.

Project management in software development: popular methodologies

The most widely used software project management methodologies include Scrum, Kanban (both belonging to the Agile family), and Waterfall.

Other, less popular approaches to project management in software development span: the incremental development model, the spiral model, PRINCE2, and the Rational Unified Process (RUP).

Scrum

One of the most popular approaches to project management in software development, Scrum breaks down the development process into sprints, two to four weeks each. The sprints are typically preceded by thorough planning. A good fit for projects with a high level of uncertainty, Scrum relies on cross-functional, self-organized teams and embraces the idea of incremental development based on observation and experimentation.

Scrum-based project management in software development is a bit different from traditional management as there’s no PM as such. Instead, the responsibilities of one are shared between a Product Owner and a Scrum Master.

Kanban

The peculiarity of Kanban is that there are no explicitly defined iterations. It is a lean approach to managing software development projects that help visualize project scope, limit work in progress, and ensure a smooth flow of work. The methodology uses physical or digital kanban boards that represent the team’s unique work process.

Due to its nature, the model is a good fit for support and maintenance projects. Another peculiarity of Kanban is implementing a limit to the amount of work in progress. The methodology aims at balancing the scope and resources. Tasks are pulled as the available capacity allows, rather than pushed into the process when requested.

The responsibilities of managing a software development project are typically shared between two roles essential to Kanban: a service delivery manager and a service request manager. The former is responsible for boosting the efficiency of workflows, while the latter is mainly engaged with interpreting the client’s needs and expectations.

There’s no need, however, to hire additional team members to fit the Kanban rules. In reality, an experienced PM is usually well-suited for both roles.

Waterfall

In contrast to the Agile family, Waterfall-based project management breaks down a project into distinct, sequential phases.

Traditionally, a new phase starts once the previous one is fully completed. Modern Waterfall projects, however, allow some degree of overlapping. It’s quite common for a test team, for instance, to start verifying individual features during development.

The Waterfall approach to managing software development projects works well for projects with predictable scope, still, it can leave development teams flat-footed and unable to adjust faster than the competition.

Since there are peculiarities in project management in Waterfall and Agile, let’s dive into the key differences.

What’s the difference between Waterfall and Agile project management?

Let’s now have a more detailed look at how management practices differ in Waterfall and Agile projects. We’re comparing the two since they are more common than other project management methodologies, and there are significant differences in how project work is organized in both. The latter influences the role and the responsibilities of a project manager (or a respective role in Agile.)

Project planning

In Waterfall, it is impossible to move forward without a thorough understanding of what you’re building and why. That is why crafting an is the number one priority in Waterfall projects. Usually, the SRS is written by a business analyst. But in the absence of one, a project manager can take over.

Agile, on the other hand, allows for more flexibility. Introducing product and process improvements on the go is the essence of Agile methodologies. Planning activities are usually carried out one sprint in advance. The backlog is created during the so-called sprint zero.

During sprint zero, the team comes up with a minimal number of user stories to turn into a workable product and, optionally, sets up the infrastructure for development. The sprint is usually kept lightweight and high-level.

Project scope management and budgeting

In Waterfall, the solution scope must remain intact throughout the projects. Change requests are managed through the Change Management procedure and are billed separately. Project management in Agile software development offers more flexibility in terms of scope management but makes it hard to assess the impact of scope changes on the final software costs. This affects the approach to project budgeting.

In Waterfall, budgeting is top-down, controlled, and based on a detailed business case. Such an approach makes it possible to give a realistic cost estimate once the requirements have been elicited and analyzed. The major downside is that this approach doesn’t work in volatile, uncertain, and ambiguous environments, which software development projects often are.

Agile’s way of managing software development project costs is responsive to change. And that is both an advantage and a complexity. Agile budgeting is aligned with the structure and the timetable of the project. And since it follows the sprint structure, too, it is easier for the team to adjust to changing circumstances — without that affecting the entire project budget. The project manager just recalibrates the expenditures in the next planning round.

Project deliverables

By going the Agile route, companies get an increment of new functionality or some other deliverable — be it a technical vision, a working feature, or an MVP — after each iteration.

In classic Waterfall, on the other hand, a client doesn’t really get any coherent, working solution until the end of the project. The full-scale testing activities are also conducted later in the development process, which might affect the time to market.

Project documentation

Proper, documented planning is a must in managing software development projects according to Waterfall. Project requirements must be clear upfront, and each team member should be aware of them. Each team member should also understand what their role within the project is and what’s expected from them. This information is usually documented, too, and distributed among the project team.

Waterfall teams refer to the documentation frequently throughout the development process to make it easier to track progress. And that’s the only way to do it — considering the length and complexity of projects typically managed according to Waterfall. Documentation takes place at every phase, ensuring everyone is on the same page about the project’s progress, despite the sequential nature of the model.

While extensive documentation serves risk reduction in Waterfall, it lowers the adaptability to change in Agile. Therefore, it is common to produce less documentation in Agile projects. And if it is produced, the documents are kept concise.

But despite a common misbelief, there’s nothing in the Agile methodology that inherently prevents teams from creating as much documentation as they need. Some documents are, in fact, absolutely necessary.

Adding user stories to the backlog, drafting wireframes, and documenting client meetings are a must. What Agile suggests is being smarter about the documenting process and avoiding too lengthy documentation.

What are the responsibilities of a project manager?

The responsibilities of a project manager will differ, too, based on the approach to managing a software development project. Let’s see what a PM or a respective Agile role does precisely at each stage of the project.

In Waterfall

A project manager is the most important role in every Waterfall team. They are the ones responsible for the quality of the deliverables and the project being completed on schedule. Their main responsibilities include supervising the project activities and designating tasks for team members.

Let’s now break down the PM’s scope of work into phases.

In Agile

An Agile project manager prioritizes the backlog items for each sprint, monitors the development progress, and establishes effective communication within the team, as well as between the team and stakeholders. They also monitor risks in each phase of the project and make sure the development process adheres to the Agile principles.

This is what a project manager does specifically at each stage of an Agile project:

What are the pitfalls for a project manager to look out for?

The key to success in managing software development projects is being able to prevent and avert risks. The common pitfalls a good PM should look out for span:

Having no control over the scope

Especially in Agile, it is common for clients to request additional features on the go, which often makes projects go awry. A project manager, thus, needs to put a clear change management procedure in place to prevent scope creep. They also need to make sure the stakeholders are on the same page about the impact of changes on a project timeline and resources.

Not focusing on meeting the delivery date

Developing a product with strict time-to-market requirements, for instance, an educational app that needs to be released before the start of the school year or a retail app that must be rolled out in time for Christmas sales, a PM needs to strike the right balance between staying on time and ensuring high quality.

They need to invest extra effort in prioritizing features and setting deadlines for each feature to be delivered. The quality requirements must be defined upfront, too, to avoid issues arising after the rollout.

Failing to establish effective communication

Effective project management in software development calls for effective and transparent communication. Establishing one is the PM’s key responsibility. They need to keep the team informed of stakeholder decisions and regularly inform the stakeholders of all the project activities, bottlenecks, and challenges.

Failing to establish clear processes

Following a software development process may seem like a burden to the team members. Still, it is necessary to set up a clear workflow that is tailored to project specifics. It’ll structure the work and make expectations clear.

Relying on unfamiliar technology

The project manager needs to ensure that the engineering team focuses on solving the customer’s business problem when making technology choices. They also need to verify that the chosen tech stack is in line with the engineering best practices.

Another technology-related pitfall is failing to plan for scalability at the early stages of product development. Thus, we advise defining the scalability requirements along with other non-functional requirements upfront.

Failing to think over the rollout process in advance

The rollout process is often overlooked at the earlier stages of development, which leads to critical delays during deployment. Healthy project management in software development requires a PM to ensure that the rollout and installation issues are thought out early in the development process.

How to approach project management in software development: ITRex’s perspective

We sat down with Alexander Belkavets, Lead PM at ITRex, and interviewed him about how we at ITRex approach software project management. Here’s what we’ve learned.

What factors do you rely on when choosing an appropriate project management model for our clients?

Alexander: There are many factors behind choosing this or that approach to project management. The most important ones are project scope, budget, and time-to-market.

If we are working on a product that needs to be updated regularly to continuously generate value for end users, say, a gaming app, we would naturally opt for Scrum or a Scrum-like approach.

If, on the other hand, we’re working on a software solution commissioned by a governmental entity, which usually means the budget is fixed, we would rather opt for a Waterfall-like approach to ensure the needed predictability. It is not uncommon, though, to split the development phase into smaller iterations. So, we often resort to a hybrid approach that allows us to benefit from Waterfall’s predictability and Agile’s continuous improvement and speed of delivery.

Do any other factors influence the choice of a project management methodology?

Alexander: Sure. The sector a future solution will be used in, certification needs, the willingness of the client to be involved in the process, and many other factors affect the project as well.

In developing healthcare solutions, for example, it is common to opt for Waterfall. In the US, before one can market, say, a novel healthcare device, they must get it FDA-approved; and that requires extensive documentation, which would be impossible to ensure following Agile.

What exactly does your role as a project manager entail? What is your key objective in managing our client's projects?

Alexander: I look at my role as a project manager from two perspectives.

The first one is: managing a project is managing risks. Software development projects are prone to many risks — from inherently faulty requirements to inadequate sourcing to changing technology landscapes and beyond. The key goal of a project manager in this respect is to minimize the impact of risks on the project and, thus, maximize the possibility of software being delivered successfully.

The second perspective is: managing a project is becoming a sort of integrator that enables many project subsystems, like development, testing, and deployment, to come together harmoniously. The key goal of a PM is orchestrating all processes within the project in a way that triggers fewer risks and ensures maximum utilization of resources.

Can you think back to a project wherein a chosen approach to project management turned out to be the decisive factor in ensuring a product’s success?

Alexander: We were developing a mobile application for our client, and we kicked the project off with Scrum. Once we released the first version of the app and got the first product metrics, we decided to switch to Kanban.

To retain the first users, we needed to continue delivering new features regularly, though two-week sprints were no longer necessary. Kanban allowed us to adapt sprint length to the complexity of new features, with an average sprint of three to four weeks, so we kept on with the delivery pace without putting the development team under extra pressure. As a result, our client managed to retain and attract new users.

Because Agile teams are positioned to be self-managed, it is tempting to come to believe that a project may as well be completed without a dedicated project manager. Is it so?

Alexander: In case there’s no dedicated PM, the responsibilities of one would have to be spread thin across all team members. One will still have to put time into prioritizing the backlog, procuring resources, reporting, and carrying out other essential management tasks. But in the absence of a PM, these tasks would be delegated to people with no specialized expertise. That doesn’t help maximize talent utilization.

A no-PM approach may work for a small team of 3-4 people but when this number gets bigger, having a dedicated project manager becomes vital.

If you still have unanswered questions about managing software development projects or are willing to hand over the responsibility of guiding your project to an experienced partner, .

Also published .