4 Steps to Start a Successful Software Project

4 Steps to Start a Successful Software Project

In my previous post Swipe Left. 5 flags to watch for when choosing your software team we discussed how to select a good software team to deliver your project.

Doing your due diligence up front while picking your team is obviously the best answer, but today we’ll talk about how that’s just step one.  Now that they are about to start work, don’t take your eyes off your software team for a second!

And remember, if you’ve got good contracts, you can stop at any time.

Hire fast. FIRE FASTER.  Your money will not last long with a bad software team.

1. THE KICKOFF

You want to start off on the right foot, and meet your software team – your real software team, not the one you may have talked to during the sales process. Everyone should be on the call, and you’ll all get introduced.  

You or your Product Owner will be asked to reiterate what the goal of the project is – the team need to hear it from your lips.  Don’t let their PM tell you.  This, right here, is your first sanity check.  The software team and you both need to be listening closely, and immediately ask questions if any facts are misstated or missed entirely.

Talk about deadlines – if you have real dates, mention them.  Get agreement on high level milestones and priorities.

By the way, who is in the kickoff..  Executives? Client Success Manager? Engineering Manager? Team Lead? Make sure you get (and share) a contact list with everyone’s role and contact information.

Talk about communication cadence in this meeting. Setup regular, recurring touchpoints at various levels – we’ll talk about that more later.

2. THE BACKLOG

One of the first meetings you’ll have after kickoff is one of many Backlog Grooming meetings. It’s critical that you or a delegate who can make decisions on your behalf attends every single one.  

If the software team knows what they’re doing, they will insist on your attendance. Miss one meeting and your project is immediately at risk.  Miss two, and the project should PAUSE. Not limp along using assumptions of what should happen next.

Software teams do not do well on auto-pilot.  Don’t let Engineers make product decisions.

During backlog grooming you’ll decide on what will happen next, and in what order. After the initial infrastructure build-out, what gets built is entirely under your control. You should be able to iterate, pivot, or reprioritize the project during these meetings – although depending on the contract structure there may be Change Orders generated by scope changes. 

Ideally you have an Agile T&M contract where you can adjust the project direction each sprint.

3. THE DEMO

Watch for regular demonstrations of your product.  You should be invited to see your product, and get your hands on it.  How does it look and feel?  If something is not quite right, bring it up immediately.  Talk it through, and correct as necessary.

Giving early feedback to your software team is critical.  If you don’t have this opportunity to touch your product, or if they are unresponsive to your feedback, you have a problem.

Get your product into the hands of actual users or prospective users as soon as possible.  That’s a great sanity check for you.. don’t build a product that only you want. Let them play on the demo environment without any instruction, and just watch what happens.

4. THE FEEDBACK LOOPS

I talk about communication ad nauseam, and here I’ll do it again.  

Quoting from an old blog post of mine:

I see examples every day where problems with software development projects or teams can be traced back to poor communication. I’ve seen people fail, projects fail and even companies fail, when an open and honest conversation could have saved them.

To be fair, it’s your responsibility to communicate effectively too, not just the software team, so if they aren’t leading the conversation don’t hesitate to step forward.

Here are some obvious ways you need to communicate with your software team:

  • Weekly Status – you should get regular status reports. Look for ‘traffic lights’ (green, yellow, red). Look for a list of blockers – YOU might be the blocker! Is the project on schedule, and on budget?
  • Retrospectives – it’s a huge plus to have regular retrospectives. It’s how you can continuously improve the project and the team in a safe, blameless space.
  • Impartial 1x1 – a good team will offer a touchpoint where you can speak to someone not directly involved day-to-day with your project.  This could be the original Sales Contact, a Client Success Manager, VP Engineering, or even an Executive at the company. This is your chance to be super-candid.  It’s your chance to give feedback on even the senior team members or project manager.

If there is any ‘wobble’ in communication, work up the chain until you find a sympathetic ear.  And if you don’t find one.. well that’s a signal too.

Worst case, I’m happy to be that sympathetic ear! Ping me any time.


James Shaw

About James Shaw

Co-Founder and Chief Operating Officer

James has been professionally programming for 30 years starting in C, C++, and moving to C# in 2000. He has received the ASP.NET MVP award 3 times and was a founding member of ASP Insiders. His recent roles have been less programming and more helping engineering teams improve, in roles such as Director or VP of Engineering.

  • Responsible for leading over 100 software engineers
  • 3-time Microsoft ASP.NET MVP Founding member of ASP Insiders
  • Owned, built and exited 3 startups
  • Started a charity with his wife to help women protect themselves from violence, Beating Violence
View author