This article provides a simple JavaScript project checklist that you can use in your own projects.

This is the second in a three part series of articles all about using checklists in your projects: why it's important, creating a checklist you can start using, and what lessons we've learned from our checklist.

Here's what will be covered:

• Why we did this
• The checklist itself
• The questions, and the reasoning behind them
• How we created this checklist
• The data used (from Bitovi's projects) for this checklist
• How to contribute your own project data back to this project, so we can continue to improve and evolve the checklist as a community.

If you're interested in the results of our data analysis from using this checklist on Bitovi's 9 years of projects, read about it here.

Why we did this

Have you ever been a part of a project where you (the JavaScript developer) did everything right and yet, for some frustrating reason beyond your control, the project failed miserably?

As developers, we like to think that a team of rock star developers is all it takes to cure all ills; but, unfortunately, software projects are a team sport. If we want to win as a team, we have to examine all factors that could lead to success or failure.

At Bitovi, we really wanted to figure out why some of our projects have succeeded and others have failed. So, we took our dozens of projects, broke them down by various factors, and ran the numbers to see which factors most often lead to success.

We used the strongest correlating factors to construct a JavaScript Project Checklist.

Why use a checklist? They transform industries and lead to continued success. We wrote about that in more detail here.

The Checklist

As a software community, we care about a lot of things, from performance, to maintainability, to reuse. But these are really all just a means to an end, and that end is project success.

When it comes to a tool that helps ensure better rates of success, an old fashioned “checklist” has a great track record.

Here's our checklist, and its Github repository.

It's in a single page, printable format for your convenience. We encourage you to print it and use it on all your projects.

If you fill it out and submit the form, it will tell you your projected percentage chance of project success, using a formula derived from our correlation factors in our project data.

The Questions

The purpose of a checklist is making sure you don't forget something important. Our JavaScript Project Checklist includes every factor that we found contributed in any significant way towards success.

The questions are not meant to be an exhaustive list of all the necessary steps in a software project, but rather they identify critical attributes we’ve observed of successful teams. If your team doesn’t meet part of these standards, consider it an indication of where they can improve.

The checklist is broken into 3 major sections, each having a few subsections.

1. Development

The dev team's job is to build the software. We've found that the areas that differentiate successful teams from unsuccessful ones are not the things we find ourselves arguing about most often, such as whether we should use React or AngularJS, but rather, the less glamorous factors of software development.

The role of the dev team is:

A. Set up tools and environments.

The goal: Essential tools are in place and being used correctly.

• Are basic tools like source control, issue trackers, and continuous integration used?
• Do separate dev/test/prod environments exist?
• Are best practices in place such as: client side tests, a build system, a script to easily deploy to test environments?

Why it's important: This part of the checklist ensures that engineering discipline is in place. The team is protected from themselves with tests and CI. There is automation in places where it makes sense, like building and deploying. Teams that employ this basic level of discipline will end up saving time and preventing common inefficiencies.

B. Care about code quality.

The goal: Practices and patterns are being followed to ensure performant, maintainable code.

• Is a module loader used?
• Is code documented and tested?
• Is the service layer well separated?
• Is technical debt tracked and considered?

Why it's important: High code quality pays dividends in total cost of ownership. It takes discipline and experience to effectively track tech debt and act on it, but teams that do end up with a code base that is more nimble and able to change quickly.

C. Organize effectively.

The goal: Use teamwork to your advantage.

• Is there a dedicated QA team?
• Are team members specialized?
• Are there code reviews frequently?

Why it's important: A dedicated QA team is a big predictor of quality because someone is being paid to find bugs. Without that, bugs are often caught by developers, which is inefficient, or users, which is a problem. Code reviews and efficient team structure leads to better quality.

2. Design (aka UI/UX)

The UX/UI team plays a major role in project success by helping to create a product users enjoy. The role of UI/UX is:

A. Exist.

The goal: Step 1 is to make sure there is actually a UI/UX team, rather than having design become an afterthought (or worse, a developer's job).

• Are there any designers on the project?

Why it's important: For UX/UI, showing up really is half the battle. Many projects we've worked on simply have no UX/UI part of the team. Those projects are more likely to fail, even if the project is internal facing.

B. Perform user testing.

The goal: No one gets design right the first time, so good teams test and iterate on designs.

• Is user testing done and discussed regularly?
• What techniques are used (interviews, surveys, etc)?
• Is analytics software and A/B testing used?

C. Communicate with stakeholders.

The goal: Use documentation tools to track and report every step of the design process.

• Are design guidelines, personas, user stories, and/or competitive analysis documents created?
• Are wireframes, storyboards, prototypes, etc. created?
• Are design discussions tracked publicly in a real issue tracking tool (not emails)?
• Does a design changelog exist?

Why it's important: These questions are indicators of a mature design team. Thorough design documentation avoids inefficiencies and makes it more likely that the design will meet the needs of both the project requirements and the users.

3. Management

Management factors play a huge role in whether or not a project succeeds. The role of management is:

A. To communicate.

The goal: Clearly communicate project goals so everyone clearly knows what they are trying to accomplish.

• Is there a single project vision?
• A quantifiable goal?
• A strategy for accomplishing project goals?
• A roadmap with dates specified?

Why it's important: We've found that if these goals are not clearly communicated, it either means management is not communicating the plan to their team, or worse, they don't know what they want. This can make decision-making and communication difficult on every level. A team that is aligned in its mission is more likely to succeed.

B. Empower the team.

The goal: Assemble a capable team and give them the structure they need to be successful.

• Do employees have access to training opportunities?
• A clear organization structure?
• Is there a single person who has final say in design, technology, and copy decisions?
• Do key stakeholders meet periodically with all parts of the team (UX and dev)?
• Can something be released in less than 6 months?

Why it's important: Without a clear decision making structure and communication, decision by committee takes over, leading to inefficiency.

C. Create fun.

The goal: Create a productive environment where people enjoy working together.

• Are there company outings?
• Regular performance reviews?

Why it's important: These factors help employees feel motivated. We’ve found that teams who get to know each other outside of the office are more likely to produce effective work.

How We Created Our Checklist

We set out to determine what influences success.

There are development methodologies, like Agile, that are designed to help provide the necessary process and team dynamics that lead to success, but they are a set of opinionated philosophies that are shaped by opinion and experience. It is less a formula for success, and more a soft set of guidelines for behavior.

Unlike a methodology, the checklist is formed using data-backed steps that positively influence success. Each step is black and white. You’ve either done it, or you haven’t.

We reviewed 25 projects we’ve done over the past 9 years at Bitovi, looking for the “big thing” that went wrong or went right. We identified a series of factors that may have lead to success and identified which projects succeeded or failed.

We focused on specific, actionable steps. For example, “the team is made up of very smart people” would be a factor leading to success, but it’s not specific or actionable, so we broke it down into more achievable steps, like “customer does yearly trainings for employees”.

For every factor we identified, we used a statistical formula to figure out how influential it was towards the overall success of the project. You can take a look at our data (sanitized for companies and projects we can’t talk about publicly).

Influence Factor

The formula we used to measure the influence of each factor was:

InfluenceFactor = TotalSuccessful + TotalFailed - 1

This measures the ratio of a factor showing up in successful projects and not showing up in failed projects, and normalizes the value to be between -1 and +1. The ideal factor would show up in every successful project, but never in the failed projects, so the influence factor would be 1.

• Anything -1 to 0 is negatively correlated with success.
• 0 indicates no correlation with success.
• 0 to 1 indicates a positive correlation with success. The higher the number, the stronger the correlation.

For example, say there are 10 projects and we're calculating the influence factor of having a dedicated QA team. Say 5 of the projects were successful and 5 were failures. If 3 of the successful projects had a dedicated QA team, and 4 of the failed projects did NOT have a dedicated QA team:

InfluenceFactor = 3 5 + 4 5 - 1 = . 6 + . 8 - 1 = 0 . 4

Imagine instead, that all 5 projects that succeeded had a dedicated QA team, and all 5 projects that failed did not. That would have a perfect influence factor of 1, and this would be a perfect predictor of project success.

Of course, this influence factor proves correlation, but not causation, so we’ll examine each to see what other factors might be at play.

Bitovi's Data

Check out Bitovi's actual data (company names and projects redacted). We used 25 projects that we've completed over the past 9 years.

Contributing data

We want to continue refining the checklist, adding important missing factors, and continually getting closer and closer to the answer of the ultimate question: What makes a project successful?

The best way to get a lot closer is with the community's help. The more project data, the more accurate the data and checklist will become. If you want to help:

1. Fill out the checklist and click submit
2. Fork this repo
3. Take the JSON that is shown after submitting the form, copy it, and paste it into a file in the projects folder of the checklist repo, something like projects/costco.json
4. Submit a PR to the main repository with your new file

If we get some new data, we'll create a script that runs through all the files, runs the numbers, and produces results.

Keep reading

Why use a checklist?

Part 1 in this series, "Why You Need a JavaScript Project Checklist", talks about the power of checklists to transform industries.

What is in our checklist and how did we create it?

Part 2 in this series, "Creating A JavaScript Project Checklist", provides an overview of our simple JavaScript project checklist that you can use in your own projects.

When we applied this checklist to our previous 9 years of projects at Bitovi, surprising lessons did we learn about how to make a project succeed?

Part 3 of this series, "Your JavaScript Framework Doesn’t Matter – The Real Reasons Why Projects Fail", interprets the results from Bitovi's checklist experiment and highlights the key lessons we learned about making projects successful.