How To Manage Software Projects Like a Pro

In the digital brewing industry, the knowledge of managing a software project for any client is the most important thing. If you don’t master the delivery of software then everything you do becomes obsolete because you can’t deliver great solutions for your clients.

A lot of different methods are in use lately that are based on different agile approaches as companies like us needed an answer to ever-changing market that they just couldn’t handle with the classic waterfall approach. So lean methods were developed like Kan-Ban, Scrum, etc. But companies just ended up blindly trusting the development method of choice, quickly went through a book or two on the subject and then just asked their project managers to switch to agile. This is exactly why a lot of companies deliver poor quality products and fail in the end.

We took a slightly different approach to handle our digital brewing. We are a young company so we experience a lot of trust issues and questions when we talk to our potential clients about new business opportunities. The usual approach that new business take is to allow clients to negotiate really low price deals or offer some kind of compensation for the project in order to secure the project. But we didn't want to be like that. We are proud of what we do and we stand behind our work!

Everything is a process

We invested a lot of time and thoughts into what exactly is that we do best and what our clients expect from us. The best solution for us was to come up with crucial business processes that would define everything that we are, what we do, what our clients expect from us and what we expect from them. Since we are building our company based on transparency and responsibility we wanted everyone that will participate in these processes to be able to easily understand them, follow them and also know when and for what they are responsible, without the need for someone reminding them all the time.

Software Project Development Process

Most of us have worked in small or large teams in the past so we all had previous experience with different development processes in different companies. We tried to join all the pros and cons we could think of and created a process that suits our team best, allows everyone to follow it easily, limit the bureaucracy to the minimum, demands responsibility from team members and provides instant clarity to our customers when we present.

The Development Process

Our standard development process has 8 stages which are explained in details below:

Stage 1: End of Sales Cycle

  • Project folder is created on FS (File System)
  • Offer&Contract are uploaded to FS
  • Project documentation is uploaded to FS
  • Project is entered in PM system

Stage 2: Management kick-off

  • Define timeline and key deliverables
  • Name project manager and lead developer
  • Enter planned income into cashflow tool
  • Enter planned resources into resource planning tool

Stage 3: Project manager takeover

  • project overview by project manager
  • project overview by lead developer
  • PM prepares sprint timeline
  • PM prepares a project Backlog (with help of lead developer input)
  • PM prepares key deliverables for all planned sprints
  • PM prepares detailed task list for first sprint
  • PM gathers team and confirms or changes planned resources

Stage 4: Internal kick-off meeting

  • PM gathers entire team
  • PM presents sprint plan and the team must confirm it before start
  • PM is responsible for:
    • Everybody has access to Project in the PM tool
    • Everybody has access to GIT repo
    • Everybody has access to Project documentation
    • Everybody has access to Project credentials in our password management system
  • Lead developer is responsible for:
    • GIT repo (master, develop branches)
    • CI and CD plan
    • Jenkins jobs for all componentes
    • Project init (we have our standard stacks for web or mobile)
    • Dev server is ready for development
  • Testing engineer is responsible to come up with a testing plan that includes functional and unit tests for critical components and detailed hand procedures for the rest
  • Designer is responsible to UX and UI design

Stage 5: Kick-off with the client

  • Managers and PM present a rough overview of the sprints and key deliverables
  • PM presents the entire Team
  • PM presents the design and UX
  • PM presents detailed plan for the first sprint and the development process

Stage 6: Development (repeats)

  • Our sprints last for 14 days
  • Developers pick open tasks (they are all trained to work full-stack) that they can solve
  • Developers are responsible to finish tasks they pick or do anything in their power to get help if they get lost
  • Daily morning meeting where everybody reports on what they did yesterday, what are they planning for today and what problems they might have - the entire team discusses problems when they appear
  • Sprint overview meetings at the of every cycle (usually Friday) - every team member is asked to present a list of tasks he had assigned himself to and present the end result and also the procedures that in place to prove the tasks are completed (tests, results, QA)
    • Sprint report is written and uploaded to the project folder
    • Client report is also written and sent to the client to be able to monitor progress
  • Sprint planning (usually after overview meeting)
    • PM presents the plan for the next sprint
    • PM is in responsible to include client feedback into next sprint(s)
  • A quick Skype meeting with the client where the progress is presented and also email with the progress report
  • Regular meetings with client after every second sprint with progress overview

Stage 7: Testing an QA

  • Constant testing according to the testing plan
  • Integration testing
  • Security testing
  • Client feedback
  • Pre-production testing
  • Bug reporting

Stage 8: Production and Project Ending

  • Production servers are configured and ready for deployment
  • CI and CD are set for production environment (via Jenkins)
  • Transfer the project to our support for the warranty period or according to contract

Obviously the PM has a significant role in leading the entire process and seeing that all goes well. What makes our process awesome is that the role of PM is not that demanding and is very well defined so every person on our team who wants to participate in project management can take over a project and be a PM. This way most of the team members know the process in details and know what is expected from them in every stage.

Software Project Checklist

Starting a software project?

Get Our Free Software Project Checklist That Will Help You Build Your Project in 60 Days or Less.

Download Software Project Checklist Now!

Rules of Engagement

There are also some simple rules that everyone involved in the development process commits to follow:

  • PM coordinates the entire process with the team and with the client
  • Management and sales supports the communication with the client and help solve problems with the team
  • What a team member commits to must be finished and tested by the end of each sprint (or else… :D)
  • Every member can pick whichever tasks they feel competent for and they can complete in a sprint
  • Code must not be commited to the repository if it is not thoroughly tested (lead developers do regular checks and code reviews)
  • Sprint tasks must be completed in active sprint - we do not reopen completed tasks
  • We are all responsible for the process and every team member must help others if they need help - the common goal is to complete all tasks that are defined in a single sprint
  • Every team member briefly presents their work on daily meeting
  • Every team member presents their work in a sprint in front of entire team on the sprint overview meeting

Development Process Linked to Income

The development process is also aligned with our offers and contracts which directly transform into our income. Most of our offers include regular payment intervals where the client pays for our services on a monthly basis. We plan income on a project after every other development sprint. This forces us to plan sprints in a way that at least after two consecutive sprints client receives results for viewing or testing. This way we encourage trust and constantly deliver value to the client so that they don’t question what they are paying for. The entire process allows us to plan our cash flow and our entire operations in detail for at least a quarter ahead.

So this is how we usually manage our software projects and it turns out pretty well for us. It doesn’t matter if we are developing for a startup or a large company, the process works equally well for us and for them. We are not committed to a specific development method but we adapted different aspects of managing software projects to suit our needs, our type of work and our daily business operations.