Project managing software - which actually works.

Short answer: A software management project is the practice of getting software from an idea to users without burning the team, the budget, or the roadmap. For most teams: pick agile with light Scrum, run two-week iterations, estimate in points not hours, and only count accepted stories toward velocity. Tools matter less than the ceremony budget. Under five people? Skip the dedicated project manager.

Software management project entails managing a piece of software from an idea in someone’s head to a working thing in users’ hands without setting fire to the budget at the same time not breaking the team. That is all for this post. Now you can leave. Alternatively, you can allow yourself to stay for the job and find out parts that drop.

You stuck around. Fair enough. Turns out, most did.

Software projects don’t behave like other projects. There is a fixed sequence to various constructions such as bridges and buildings; they cannot be altered halfway through. Software projects can be changed back before complete usage, and are invisible until the user interacts with them. It alters your planning, estimating, and decision-making processes regarding future actions. If you treat software like a bridge, the whole project will run at bridge speed – a pace at which a competitor will definitely eat your lunch.

This post is a practical guide to managing a software delivery project: a working reference for engineers, anchors, or founders who were asked to do it without the training. We will discuss what project management is, how to choose a methodology, how the phases line up in real life, the two opinions that split shippers and planners, and when to not even formally run a project.

Software management project, plainly explained

The discipline of managing a software project in a way that the software gets built, shipped, and improved without one of these three going wrong budget overshooting, team burning out, and result being something nobody uses. Three failings, one design discipline.

This is how it looks when applied.

• Deciding what to build next. And what to not build next, which is the harder half.
• Breaking work into pieces small enough to finish inside a single iteration.
• Estimating those pieces so you can forecast with a straight face.
• Running just enough ceremony — standup, planning, retro — to keep humans aligned without grinding the work itself to a halt.
• Catching the meta-problem early — scope creep, broken velocity, lost focus — before it eats a quarter.

People think of a Gantt chart that is wrong, and a project manager who waves their arms at it when they think of project management. In the field of software, the Gantt chart is erroneous before the ink dries, because what is described is changing underneath it. True software project management resembles a tightly-woven feedback loop, rather than just executing a plan: build the tiniest useful slice, ship it, see what happens, decide what to do. The plan is the result, not the goal.

It is essential to note that the most significant value addition when developing software is providing the user with software that works and is clear to the user. Not a milestone document. No Jira issues on Done. A user can either perform an action that they could not previously do, or not. . Every decision around methodology, tool, process etc must be evaluated through a single lens: does it shorten the loop between when we decide something and when the user notices it? If not, leave it.

Why software projects are different from everything else

Three structural aspects distinguish software management projects from, for instance, construction projects. Each of the plans upends assumptions about planning.

Software is reversible, when deploy is bad rollback to previous state. Release an unwanted feature and eliminate it. Deploy flawed architecture, transition away from it. All hamburgers cost less than removing a wrong wall. So, it’s all about speeding up the journey to getting real feedback. Catching a mistake in production saves you a lot of money. We don’t spend an enormous amount of money on six months of planning just to mess up.

You cannot visually experience the state of a software project unless you open the application or its interface. You're exposed to JIRA tickets, status reports, and demos. Whoever is reporting them will heavily editorialise all three. Put simply, a shippable output must be created at every iteration boundary. This is because a shippable output is the only honest signal of progress. All other things are theatre.

Software is recognized as complete once it is in use, not delivery. A bridge is finished once it is opened. The software is done when users use it for the activity you had intended for them to do, and you cannot know this until after release. The meaning of this is to treat the launch as the beginning of a project and not the end. The beginning of the actual work is when your first user signs up and does something unpredicted by you.

When teams internalize these three facts, their software management projects feel like producing software. There are teams that do not conduct them like building projects, and spend most of their budget planning for problems that would have cost nothing if found in production.

Pick a methodology before you pick a tool

The most frequently observed mistake in a software management project is opting for Jira before recognizing the methodology for which it will be utilized. The tool receives data. The selection is the selection.

There are 4 methodologies showing up in the SERP, and you must be honest about which one does.

Agile means iterative feedback that assumes change. Most software work defaults to winner. Your users will interact with your product and want it to respond. Your APIs will change under you, the guidelines of the platform on which you operate will twiddle the knobs and your founder will have a new idea every third Friday. Any of this will break a linear plan. The canonical reference refers to Agile Manifesto, a text comprising four principles written in 2001, which still remains correct 22 years later. Four as opposed to forty.

Scrum is a specific agile flavor with a structure formed of sprints (typically two weeks), daily standup, planning, review, retrospective. It functions effectively if the team recalls that Scrum is scaffolding, not religion. A majority of the failures of scrum arise out of running ceremonies to the letter and forgetting they exist to serve the work. The Scrum Guide is short; read it once and execute it like an engineer, not a priest.

Waterfall: Everything planned upfront and executed in sequence. It's okay for projects with fixed requirements and no user feedback loop, for instance, regulatory paperwork, embedded firmware tied to a date launch. Most software will not be fine with that. Software lives on what happens at the user end after a release. Waterfall is structurally incapable of using that signal because the plan is already laid down before any user touches anything.

Implementing a pull-based flow and work-in-progress limits. Ideal for support teams and continuous maintenance work. It is not a good practice to develop new products as there is no rhythm which means no forced retrospection and no cadence. A good rule of thumb: Scrum until product live; Kanban after, if work shape warrants it.

Most teams should start with agile with light scrum. Planning, retro, iteration, standup in two weeks. Eliminate any ceremony that is no longer worth its price tag. Avoid conducting a sprint review when it’s just going to be for three people who were all in standup an hour ago.

The Capterra reviews call LiteTracker “a good tool for agile practices” because LiteTracker is built around XP-flavoured agile. By this we mean iteration, velocity, accepted-stories-only, and so on. Following the Scrum principles, the tool matters less. Whether you are running XP or running Scrum lite or intentionally dropping ceremonies that are not earning their keep, pick something that embodies that position by default and not one that requires battering into it.

The five phases that actually run (and why they overlap)

If the scope of a software management project is reasonable, the timeline from concept to a polished version of the software goes over a period of around 22 to 31 weeks. The figure.

Three candid observations regarding this graph.

The design phase does not get over when the development starts. These phases overlap. Discovery is not something you do until week 3. Testing is not a phase that sits at the end and waits. In real software projects, the front stage focuses on strategy; the back stage emphasizes polish. Meanwhile, the middle stage focuses on development iterations in which everyone is contributing in parallel to shape the output successfully. The table presents a useful falsehood for stakeholders who need to see boxes. It is not a timetable.

The main development process relies on iterations and not on phases. Furthermore, the twelve to sixteen weeks of development uses six to eight two-week iterations. With each iteration goes a vertical slice of user-visible value which the PM accepts. Shaping the sprint in this structured manner helps teams ship up to 70% more value by their eighth sprint. The mechanism here is a forced-shippable discipline at every iteration boundary, which prevents the drift that kills most projects. If the iteration ends and you can’t point at a thing a user can now do, the retro is the most important meeting of the week.

When core development runs late, shorten QA is the universal cop-out. Don’t. Testing & refinement will try to compress. There’s always a pile of bugs you didn’t know about which the buffer exists for. Either delay the delivery or lessen its scope. Speeding up QA will result in faster bug releases, which is not what you want.

to help set internal context, you might find it useful to borrow from the adjacent reading on MVP project management and kanban planning – both of which go further and deeper on the mechanics of running the actual development phase

The real deliverable is shippable software

A software management project often leads to the temptation to measure progress by hours burned, tickets changed or velocity numbers. The three aspects have a low correlation with what actually matters. What matters really is: is there software today that users can touch, that there wasn’t yesterday?*.

The right unit for user-visible value is a story that narratively describes one piece of that value. Not an incident report. Not something engineers do. If you can explain what has been accomplished by describing what the user can now do, that they couldn't do before, then that is a story. When the only way to express it is through code or component language, it’s a mechanical job in disguise.

Example. The naive take on authentication is one huge tale.

A user can sign in, and sign out, and recover their password, and change their password, and recover their username.

That’s five stories attempting to pass as one. Use every “and” in a story headline as a place to split. When executed accurately, it materializes into...

• A user can sign in
• A user can sign out
• A user can recover their password
• A user can change their password
• A user can recover their username

Each of these is valuable, shippable, acceptable on its own. Once ended, each will appear on the burndown, rather than one monster story sitting at 80% for three iterations.

When a ticket tracking system is introduced, it will optimise for the backlog getting smaller. A tracking system will most likely show progress relevant to users. Choose the option that corresponds to what you wish to ascend. If you want to know in detail how to split the work this way, check out the backlog refinement meeting guide for a companion piece.

Estimate in points, not hours

Engineering retrospectives over the past decades have highlighted that engineers tend to give poor absolute time estimates but reasonable relative size estimates. A developer can answer the question “is this harder than that?” There’s no honest answer to the question, “how many hours will this take?” that isn’t “I don’t know, it’s software.”

The workings.

1. Use a short Fibonacci scale: 1, 2, 3, 5, 8. Five buckets is enough. Any finer pretends to a precision that isn't real. No 13s. No half-points. The constraint is the discipline.
2. Estimate features only. Bugs and chores don't get points. They are not new value — they are recovering lost ground or supporting infrastructure. Pointing them inflates velocity and converts it into fiction.
3. Track a rolling three-iteration velocity average. That's the team's forecasting number. Not a target. The moment a manager treats it as a target, the team games it, and you lose your forecasting tool at the same time.
4. Use velocity to forecast, not to grade. "We have 80 points of work and a velocity of 18 — we're four to five iterations out" is a useful sentence. "Velocity dropped this week, what happened?" is a worse sentence, and asking it weekly is how you break the practice.

It does because velocity self-correct. If your team keeps overcommitting, their average will drop and forecasts will be more honest. Estimates do not have a feedback loop. They are merely guesses and repeated on a weekly basis (with no improvement feedback mechanism for the team).

Such a preference is not stylistic. It is the one decision that differentiates software projects that progress from those that linger. For a more detailed explanation of why relative sizing is better than absolute sizing, please refer to this link.

Three ways a software management project rots

Most software projects that fail do not completely collapse. They wear away. Three early indicators of the breakdown of discipline

Conversations steer the ship and prevent scope drift that “just happens” when no one is looking at the map. The product requirement document (PRD) is open in a tab and nobody has looked at it in six weeks. Suggested rewrite: Ensure the PRD is pulled into each backlog grooming session; basically, stop every new feature with “does this directly help us hit the success metric defined in discovery * If the answer isn't clear, it goes into the icebox until it is. The problems in project management analysis explores the pattern in detail.

How Stories are Getting Smaller and Velocity is Going Up Points are awarded for bugs and chores, resulting in a more vibrant chart. In one-on-ones, the PM inquires as to why velocity is decreasing. Refrain from debating velocity as an aim. Talk about accepted stories as an output. Use velocity for predictions, but avoid referencing it anywhere else in the scrum process.

The team invests more time documenting or communicating their work than actually carrying it out. We have standups for thirty minutes, four hour planning sessions, retro becomes a complaining session, and now there’s an “alignment sync” on the calendar! Modification: Eliminate a ceremony at every retrospective until the team feels there’s progress. You will not be arrested by The Scrum Guide. It is unable to apprehend anyone in a legal sense.

The common root cause behind all three incidents is the same; the process has run ahead of the work. The cure is always the same; shrink the process until the work shows again.

Tools matter less than the ceremony budget

We've deliberately refrained from suggesting tools so far here's why. The tool comes after the methodology阶段. It is important to always start with the methodology first and then move to the tools.

Said that, the landscape 2026.

To put it bluntly, every team has used a tool you find clunky to produce great work, and every team has Jira configured to perfection but remains useless. The tool is not the bottleneck. Budget For Ceremony is The ultimate consideration is the PM's capacity to determine the next steps and the team's ability to accept the answer, if any.

LiteTracker focuses on the 20% of features that make up 80% of the results for a software management project iteration, velocity, acceptance, standup, planning, retro and ignores the other 80% that slows enterprise tools down to a crawl. The analysis in engineering project management software and product development platform digs deeper for comparisons in the broader category.

When NOT to run a software management project at all

Many developers have been instructed to treat every piece of software work as a project. Don't. Feed with competent people, give them room, and they will naturally find a way to get things done.

If you have _________________, you probably don’t need formal software management.

• The team is under five engineers and there's only one product. The founder or anchor can hold the roadmap in their head. The standup is the project meeting. Adding more structure buys nothing.
• The scope is one feature with no cross-team dependencies. This is a chore, not a project. Spin it up, ship it, delete the branch.
• Nothing has shipped yet and the question is still "what are we building?" That is discovery, not project management. Treat it as such. A PRD, a few user interviews, a smallest-useful-thing experiment — not a Jira board.

Chances are you do, if.

• The team is over eight people on one product, or you're running two products with a shared backlog.
• You have cross-team dependencies that break if someone slips a release by a week.
• Someone outside the team needs to know when something will land, and the answer "when it's done" won't fly.
• Compliance, audit, or contractual commitments need a paper trail.

We make this claim as a tool vendor. If you are three engineers in a Discord and we would be charging you nothing on the free tier and adding a layer of process you don’t need, we’d rather you not sign up. Use a common document, conduct your own standup, and return when the actual friction arises. The project-management industry may tell you the opposite, which tells you something about the project-management industry.

Frequently asked

What is a software management project?

The process of transforming software from an idea into a functional and released product using a disciplined approach without breaking the bank, team or roadmap. This involves determining what to create, dividing it into manageable tasks, providing estimates, and including just enough ceremony to keep the team aligned without stopping the work.

What's the best methodology for a software management project?

The majority of teams are exhibiting Scrum Framework with Agility. Plan, Stand-up, Retro Forms of Event. Discontinue any activity that does not yield a return on investment. The waterfall model doesn't suit most software projects because user feedback is absent until the software is released.

What are the phases of a software management project?

The six phases of a project are discovery and planning, design and architecture, core development, testing and refinement, launch and post launch. Phases practically overlap in actuality. Core development relies on iteration rather than phases.

Why estimate in points instead of hours?

Through history, engineers have been poor at estimating time in terms of absolutes and reasonably good at sizing things in terms of relativity. Points enable you to estimate based on observed velocity, which self-corrects. No feedback exists to improve the accuracy of a time estimate; it's just a stab in the dark repeated weekly.

Should bugs and chores count toward velocity?

No. Bugs originate from a story which returns. Chores do not add new user value; they are infrastructure components. Either pointer inflates the velocity and converts it into fiction. Consider only accepted features.

Do I need a project manager on a small software project?

Likely not. If you are hiring under 5 engineers, you are hiring someone to co-ordinate calendars. Appoint the engineer who's doing it informally in the first place and empower them.

How is a software project different from a construction project?

Software can be reverse engineered, renders invisible, and is user-defined post-release. Construction cannot be reversed, is tangible, and is accomplished through delivery. The take-away: PYX transform 2023; focus on fast feedback loop, not correctness.

When should I stop running a formal project structure?

The scope can be one feature with no cross-team dependencies, or a team of under five engineers on one product. If we do not need a formal process for something, it ends up being overhead and it taxes the actual work.

Still stuck

Once the methodology has been settled and the discovery is done, if the team is shipping accepted stories in iterations, then most of the value of that software management project is already captured. The final ten percent consists of tool choice.

LiteTracker is for working that way if you want velocity-based forecasting, accepted-stories-only, points-not-hours, and a tool that only lets you work that way. Our free plan allows unlimited users and has no demo call or credit card requirement, with no time limit. Use whatever tool helps the team the most a shared Trello board and a Discord ping are fine! We don’t want you to pay us for existing friction.

In any case, do not continue with the standup unless it has useful directions.