"How quickly can the project start?”

Congratulations! Your project just got signed! Budget, scope of work, and development time-frame have been approved. Now only one question remains, how soon will it take for you to see progress?

The answer is "probably not right away."

"Why not?," you say.

Let's help you understand. First, it's important to remember that a number of things must be set up to ensure the success of the project. Whether this is a brand new development project or an improvement upon legacy software, developers will not be able to work efficiently until the following happens:

1. Project management tools must be set up

The details of the project must be captured and documented in a central location where information can be easily updated and researched. Ideally it should allow for the management of business requirements, system requirements, as well as time and budget management. A smart ticketing system that is coupled with a wiki system, and links to the source code repositories, is key. A ticket workflow will also tremendously facilitate the testing and debugging process.

We have been using Trac for years at Six Feet Up. As an open source and Python-based program, Trac has allowed us to heavily customize its features to fit our specific business processes.

So, before the project can start, here is what needs to happen on our end:

• A Trac instance must be set up for your project
• Trac accounts must be created for your team so you can follow along, be kept in the loop, and answer questions whenever they arise
• We need to set up your project in our time managing and billing tool for accurate reporting of where time is spent

2. Development tools and environments must be set up

In order for the development team to start work, engineers need the boilerplate code for the project. This involves using some code generation tools to get the basis for the project setup. Then the source code repositories for each piece of the project need to be set up. The code can be hosted by Six Feet Up or on a service like Github.

Once the code is ready to go, then there needs to be a place to test and review with you. A testing and staging instance of the project are set up to facilitate this need.

3. Access to your system must be set up

If the project needs to be deployed to a system outside of Six Feet Up's network, then access needs to be granted. This sometimes involves getting VPN access to a third party system. Depending on who runs the service, it could take some time to get the credentials and access sorted out.

If the project involves a site that has already been created, the developers cannot start until they have access. This involves getting a copy of the database, code repositories and various logins needed to access the site.

4. A knowledge transfer from sales to PM and Tech Lead must take place

Most likely the details of the project have, to this point, only been shared with our business team. Those details now need to be shared with the project manager and the developers who are to work on the project.

"It's crucial to establish a clear, high level picture of what it is that needs to be built, and why."

At this point it's crucial to establish a clear, high level picture of what it is that needs to be built, and why. The why is absolutely key as it will guide decisions down the road and will help align efforts among all the participants.

This knowledge transfer usually happens in the form of team meetings, oftentimes augmented with client meetings when the development team has questions that weren’t previously asked by the business team.

5. A detailed SOW must be defined

Once the overall picture has been shared with all, there comes a very critical time when the project’s vision must been translated into actionable chunks.

Here’s how we go about it, whether it is a four-figure project or a multi-million dollar project:

1. Develop user stories when necessary to keep the team focused not on the features but on the benefits to the end-user
2. Develop wireframes and mockups if necessary to communicate clearly how the system will need to behave, which components will get reused, and what the end-users’ experience will be like.
3. In the case of a complex implementation, develop system architecture diagrams
4. Capture the requirements in Trac:

• Create business requirement tickets and assign the corresponding child technical requirements that need to be done in order to fulfill the parent business ticket.
• Provide effort estimates for each business requirements to help you make decisions as to what needs to be worked on in each phase.
• Organize the work in components/large feature sets. This facilitates research down the road when the system is documented in hundreds or thousands of requirements. This also allows the project manager to assign pools of related work to the same developer, in order to minimize knowledge transfer inside the development team.
• Capture all the technical information that can be useful in wiki pages (e.g. links to testing, staging and production environments, notes about legacy decisions, gotchas, specific implementations, users guides, etc.)
• Assign tickets to the appropriate technical personnel (e.g. theming work goes to template developers, database work goes to the db expert, solr work goes to the search expert, Pyramid work goes to Pyramid expert, etc.)

6. Onboarding of the technical team must be coordinated.

Developers will need to spend time to get familiar with either the existing system or the architecture of the new envisioned software.

In the case of a pre-existing site, they will investigate what is currently in place. This involves looking at how the site is deployed, reviewing existing code to see what has been done, and reviewing any documentation that may already be in place. Our developers also get a chance to see if any of the Python code is PEP8 compliant and what architectural decisions have been made.

If there is no pre-existing site, this is the point where our developers will review any business requirements or technical documentation that has been created. They will be able to have discussions with the project manager and client to figure out what solutions will fit the needs of the project.

Conclusion

Robust deployments rely on solid foundations. So how much time should you expect Six Feet Up to spend on kick starting your project? At a minimum 5-10 hours for really simple software development projects, and much more for more sophisticated implementations.

Again, it is important to remember that the size of your project will determine the time it takes to get it moving in an effective manner. If you have questions about any of the information in this article, please contact us or leave a comment below!