Starting up any new IT project can be a stressful time. It shouldn’t be, however, and it needn’t be either if you choose a development team that puts communications and project organization at the forefront of all its processes.
Getting started can often feel like the hardest part of any new endeavour that you choose to take on – fear of the blank canvas can apply to any professional, not just the struggling and tortured artist. And when it comes to the blank canvas of your exciting new IT project – whether you’re having some bespoke software developed for your offices, or are moving into the realms of mobile or web apps – there are literally hundreds of things to think of, and deciding where to start can sometimes lead to a state of paralysis.
But a good development house will have dealt with situation many times before, and through experience will have developed a unique and streamlined process that cuts through any feelings of anxiety in order to get any project off the ground to a flying start, with all parties feeling confident and comfortable about the coming days and weeks.
The most important thing, as ever, is communication. As a client you will be keen to know and understand the processes and workflow of the development team The development team will be equally keen to ensure that the client is fully prepared and equipped for the project going forward and that functional communication pathways are established for good cooperation throughout the development process.
Bearing all of this in mind, best practice dictates that the development house should have a workflow model already structured right from the moment the first meeting between client and dev team commences. Here’s how to launch a successful project without unnecessary fuss and stress.
Phase 1 – aligning the client’s vision with the dev team’s plan
Before any development work commences, it’s absolutely crucial to ensure that everyone is working towards the same goal and has the same vision for the project. The whole process needs to be thoroughly planned out, with everyone understanding exactly what features are required of the app or software, what the overall purpose of the programme will be, and what the initial goals of the project are. A Product Design Sprint or a Scoping Session are both great ways to kick off the planning phase of the project.
The most important things to be established in the initial stages of the planning are:
User and client personas: the development team needs to understand exactly who is going to be using the final product. If it’s a piece of bespoke office software that has been commissioned, then the dev team needs to know how the office employees operate and exactly what the software will be helping them achieve. If it’s an app that you’re developing, what is the target market?
What need the project will be satisfying: it’s important that, as a client, you provide the team with any market research that you have done surrounding the project to help them understand its purpose.
How the end product will meet the client’s needs: in response to the last point, it is important that the dev team manages to clearly communicate to the client that they are committed to the vision of the project. Each member could bring his/her own ideas to the table so that they become active participants in the formation of the idea.
SWOT analysis: what are the strengths, weaknesses, opportunities and threats to the project? It’s important that all competitors are identified, and how the new app will improve upon what’s already available.
The available budget: Clients will have a maximum amount that are in a position to spend on the project, and the development house will try and create the best deal it can in accordance with that. But this needs to be clarified from the outset so there is no chance for disagreements later (not unheard of when dealing with money matters). Also, check whether the development house of your choice uses fixed prices or hourly rates.
Any time constraints: When will the client expect the final product completed by, and does the development team consider that to be realistic and is it able to deliver in this time frame?
Phase 2 – Drawing up a software requirements specification (SRS)
The goal of your SRS is not only to create a very clear and concise document which everyone is up-to-date with and able to adhere to, but, more importantly, to assist in the creation of great software.
During Phase 1, you will have managed to outline your main goals with your development team. Now, you can create a general specification.
This should address:
What the software under development is required to do.
How the external interfaces of the software functions.
The expected performance of the software.
A product feature list.
Attributes – i.e. security, maintainability and portability considerations.
Constraints – i.e. whether or not there are any required standards in effect, policies for database integrity, limits on resources etc.
A good SRS will be an excellent resource for the dev team, and will establish a strong basis of agreement between the developer and the client before the work begins.
But specification will do so much more than that. It will form the basis for forecasting costs and timelines, and reduces the later efforts in development considerably. The drawing up of an SRS will force the development team to sketch out all of the software requirements rigorously, thusly reducing the need for redesigning and recoding later.
Indeed, ‘sketching out’ ideas in the specifications phase may be taken literally. Much like creating story boards before taking a screenplay to a film, developers should physically sketch out how they envision the interface of the software to look. This can be either using a mockup tool such as Sketch or Balsamiq, or the good old-fashioned low-tech way with pencil and paper.
Written descriptions of each module are also invaluable. And to this effect creating effective user stories are invaluable. Put simply, user stories describe exactly what the client wants from each module.
Phase 3 – giving and receiving feedback (by the client)
Before the project progresses any further, it is imperative at this point for you as a client to go away and discuss the project specifications with all who are involved. This may include your employees who might be using the software on a daily basis in the office, or the potential users of your new app.
By taking the time to do this now, you can save many hours in the future by preventing the development team from starting off in the wrong direction, or from not including an essential functionality of the programme.
Phase 4 – An Interview With the Project Manager (PM)
Your project is now moving closer and closer to getting underway. But, before this happens, it’s important that you have an in depth meeting with the PM of the development team. It is here where you will have a chance to clear up any anxieties that you may still have with regards to communications and processes.
How will the workflow be managed? How will we be alerted if we are off schedule or unforeseen problems arise?
Who is responsible for the project?
Can all of my requirements be met?
How are project priorities translated into iterations, estimations and processes?
How will the final product be distributed?
How can I help and support you throughout the development process?
After taking questions from the client, the PM will then have some questions him/herself, in order to ensure that the client’s requirements are in line to be fulfilled.
These questions will include:
Does the client have his/her own servers already?
Does the client have any preferred delivery or deployment tools?
Does the client have a technical person on his/her side – CTO (chief technical officer) for instance?
Phase 5 - preparing for the kick-off meeting
Before the project starts there’s always a kick-off meeting. But, even before this, there are a few things that the dev team will need to have prepared.
This will include:
Information on whether the development team will be conducting all of the work, or if they will be sharing some part of the project with another team. If so, then the client may have some concerns about how the workflow between the in-house and remote teams will work, and how any issues surrounding working with remote teams are solved (see 4 Common Concerns About Remote Teams Solved).
A first draft of the app architecture, which will be consulted with the client during the kick-off meeting, or otherwise during the first days of collaboration.
Phase 6 – The kick-off meeting
The final stage before development begins – the kick-off meeting. Here’s what will happen:
The team will be introduced, and all of their roles outlined – the developer(s), in charge of coding; the QA team, in charge of testing and noting bugs; the project manager, in charge of planning and communication with the client.
The client will be asked how s/he plans to earn money from the application.
The first drafts of the app architecture will be discussed and any necessary changes will be made.
A staging server will be set up with access to it granted to the client and relevant team members. The client will then be asked if s/he has a production server. If the client doesn’t have one, then the development team should provide one.
It's important for the client to understand that a strong Product Owner role will be needed during the entire process.
Phase 7 – Go!!
Everything should now be in place for work to begin. In the initial stages of collaboration, milestones will need to be set with iterations laid out that all devs are to follow consistently. It will also be in this early stage that everyone will have a clearer idea whether or not they have all the materials and information they require to complete the project. Cuts in the scope and re-estimations will occur. If anything is discovered to be lacking, it can be sorted out now so that everything is ready when the time comes.