Setting Expectations from the Start
One of the most important steps to setting up a new partnership for success is both the client and the developers need to be clear on the ‘Definition of Done’.
Maybe it’s a completely polished web application for an enterprise brand or a Minimum Viable Product mobile application for a startup. Whichever it is, both parties need to be clear where priorities stand for the end goal.
When working with developers, don’t be afraid to push them for specifics. It helps both sides really understand if they are on the same page.
Process Education
Is this your first time going through the software development process or your seventh? Have you worked with an agency, off-shore developer, or a freelancer?
Every agency has a slightly different process. Conversely each customer has their own operational preferences.
It’s important to walk through expectations and to define common terms that will be used. A good example of what this could look like is discussing the value of a story point if you’re using the agile development method.
Even if you are on a tight deadline or the developers are excited to deploy a new technology, slow down and make sure everyone understands what the development process for this specific project will be.
Slowing and defining early will allow for quicker, uninterrupted progress later.
Project & Product Owners
Every software development project should have a Project Owner on the developer side and a Product Owner on the customer side.
Project Owners could be a traditional PM or the lead engineer, but that person must be identified and responsible for the lifetime of the project.
The customer should identify a person to be the Product Owner. They will attend all regular meetings and communicate on behalf of the product/customer.
In order to set the project up for success, the Product Owner should have the authority to make product level decisions in the immediate. If the Product Owner is not the budget holder, they should have access to them for product altering decisions.
Organizational Tools
During kickoff, organizational tools should be defined. These channels and tools will act as the single source of truth.
Popular tools many teams and companies use some combination of the following tools:
- Slack
- Trello
- Clubhouse
- Asana
There should always be a tool to reference which items are in the Backlog, In Progress, In Review, Done, etc.
The organizational tools compound the benefits of process education, which was discussed earlier. With everyone on the same page in terms of process and terminology, the organizational tools give all parties the vehicle to stay in tandem.
Something Will Go Wrong (Be Agile)
- Is the API documentation for an integration incomplete?
- Is that AR feature too ambitious for the budget available?
- Maybe the designers made really complicated designs for your website.
Whatever the problem is, the success of the product and the relationship will be dependent on how the collective team responds.
Identify the problem, discuss possible solutions, analyze what will need to change regarding scope, time or budgets and make the agreement on next steps. Expect a hiccup or two and you won’t overreact when they occur.
The key to being able to stay true to this is defining in process education how unforeseen issues will be discussed and handled.
There must be a process of reporting and responding that both sides agree on. This creates streamlined solutions and a united problem solving team, instead of a bunch of fingers pointing at one another.
Regular Communication
Don’t allow any party to disappear for too long. Ensure that there is regular communication and check in’s that happen.
At Vincit, we set up weekly sprint planning meetings during our project kickoff process. Depending on the type, size, and duration of the project determines whether they should be in-person or virtual.
In these meetings the prior week’s progress is discussed. We look at any concerns that may have arisen, reprioritize our backlog items, and plan out what we’ll work on for the next week.
These regular meetings allow the Product Owner to mention any pivots or changes to features and priority or for Project Owner to bring up any recent challenges.
Transparency
Along with regular communication, the developer and customer should always be transparent with estimations, project timelines, budget utilization and remaining scope. Estimations upfront should be honest regarding time and budget needed for project completion to be done right the first time.
Underestimating can lead to conflict down the road when things are over promised and under delivered.
During execution the scope and budget should be looked at regularly to ensure they are on track. If a red flag appears, it should be brought to the entire teams’ attention and a solution set in motion.
I want to stress transparency isn’t only for developers and vendors. Clients must also be transparent with their deadlines and requests. Unsolicited, unexpected requests that are hidden and conveniently asked for farther down the project can often be the cause for major friction down the road.
What Does A Successful Software Development Relationship Look Like? Mutual Trust.
The ultimate goal with all of these is to build a mutual trust between the Customer and the Developer. If all the things in this post are set forth with honest intentions, you will find that the developer and the customer are champions for each other.
Successful software relationships usually result in the best quality products at the end of the day, which is in everybody’s best interest.
