How to Commission a Software Project: Conclusion

Author Image

This is the final article in the “How to Commission a Software Project” series.

Shipping Your Software Project

If you’ve read my other eleven other articles on How to Commission a Software Project, you’re probably ready to ship your software project by now. If you have good skills around project management, you already know what to do. Otherwise, study up on those skills or find someone who can run that for you.

For any software shipment it will be helpful to identify a toolset you’ll use to manage timelines, issues, requirements, and communications. Need some ideas? Here’s a list of platforms we have used in the past. Your mileage will vary based on management style and team dynamics, but this will be a good start:

Timelines –, spreadsheets

Issue Management –, JIRA, Trello, FogBugz

Requirements –, Word Processing Documents

Communications –, Slack, Basecamp

Key Differences Between Software and Other Projects

There are some key differences you may find managing a software project versus other, more tangible projects. 

  1. Estimates are wrong. The layers of dependencies and unknowns are so complex that when you’re building something new, there’s simply no way to know how long it will take. It’s still important to have estimates, and they’ll get better, but don’t trust them too much.
  2. Adding more people makes things take longer – at least in the short term. If you want, you can read about that as the central theme of The Mythical Man Month, or you can just take my word for it. What you really need to know is software is complex and humans are complex. And if you add more humans or more code to the project, the effort, time, and complexity will increase.
  3. Early progress is invisible. Once requirements and designs have been ratified, there’s a long period where it can appear as if nothing is happening. If you’re constructing a building, the site prep, grading, and foundation work is quite visible. Not so in software. Development environment setup, building data schemas, and the early phases of a project are not visible to the user. Give some trust to good and smart people and you’ll get it done right.

As you set out to build this amazing thing, the guides in this series should help you succeed. Find your experts and use these 12 pieces as a sanity check to help understand what they’re doing, or maybe to help admonish them into best practices.

Interested with your software project?

Get Fivable to Help