(Image credit: Adobe Stock.)
Today one sees many articles about standard practices and patterns for managing projects. But what if it’s a small project or an ad hoc initiative that wasn’t necessarily planned for? Can a standard methodology be slimmed down to something that fits the needs of a smaller project, but still provides enough structure to effectively manage it?
When working on any sizable project, decisions are typically made for development and testing in the interest of resource and time trade-offs. On such projects, the questions are something like: “Should we delay this project release to add this feature?” or “We are pretty confident in this code, so should we decrease testing time in this area?” When it comes to smaller projects, why shouldn’t these questions be applied to methodology and practices? The key is to identify what practices provide the most benefit, and more importantly, what practice can be simplified to use on a smaller project.
A comparison of two larger and smaller projects might prove instructive. For this comparison, both are full-stack web development projects. One is a large insurance quoting project, and the other a small e-commerce project. The biggest difference between the two is their scale and timeline. To set the scene, here is a quick overview of the two project structures:
Large Team Structure – Team of 18 – 2-Year Timeline:
- (2) Project Leads
- (2) Business Analysts (provides stakeholder sign-off)
- (4) Quality Analysts
- (2) Tech Leads
- (6-8) Developers
Small Team Structure – Team of nine – 6-Month Timeline:
- (3) Stakeholders
- Responsibilities include Business Analyst (provides stakeholder sign-off)
- Responsibilities include Quality Analyst
- (2) Part-time Project Leads
- Responsibilities include Tech Lead
- (2-4) Developers
Estimated project durations:
Large project man-hours = (18 team members) x (24 months) = 432 working months
Small project man-hours = (8 team members) x (6 months) = 42 working months
The large project is approximately 10 times larger than the smaller project. Given this, how might the smaller team, working on the smaller project, simplify the project communication practices for effectiveness and efficiency? Here are some suggestions:
Daily Standup: General Team Communication
The purpose of a daily standup is to spread awareness about the team’s work to keep everyone productive. In the larger project, the standup was between eight people and usually lasted 20 minutes. The biggest benefit of this process is coordinating between testers and developers.
For the smaller project, the process was simplified by using email to report any standup details. However, this proved to be ineffective because emails couldn’t duplicate the standup’s quick back and forth discussion between team members. The compromise for the smaller project was to use a longer in-person meeting (four people and 30 minutes), which kept team members with multiple roles on the same page.
Design Reviews/Code Reviews – Developer-to-Developer Communication
Design and code reviews are typically done between fellow developers. A design review occurs when a plan or structure is reviewed before it is implemented. This is important to help create well-organized code and to reduce time when making improvements in the future. A code review occurs when the code written is reviewed before testing to help catch bugs, and to help with code consistency.
For both large and small projects, design reviews are very important, especially at the beginning of the project because there are more opportunities to see the benefits of more easily extending existing functionality. Code reviews can be simplified for smaller projects because less communication is needed between developers when each person writes large sections of code. In many small projects, a single developer will write all the code for a certain feature. This removes a lot of developer coordination, and the code inherently gains the same benefits of reduced bugs and code consistency, while reducing the number of code reviews.
Business Engagement – Developer-to-Business Analyst Communication
Developer and business analyst interaction is crucial to a project, big or small. For those unfamiliar with the term business analyst, it refers to someone that understands the behavior and actions that the program will be responsible for executing. A useful way to think about it is that the business analyst knows the destination, and the developer builds the road to get there. Projects often veer off course when the two fall out of sync.
For larger projects, this is usually addressed by adding a person to the development team dedicated to the business analyst role. For many smaller projects, however, that is not a practical option. More often than not, most members of small project teams must wear multiple hats and serve multiple roles. To simplify things for this purpose, it’s often helpful to use a Google Document or something similar to act as a proxy for someone who would normally play this role full time on a larger project.
In practice, developers would add a question to the document when they encountered a question while writing the code. Every other day, a business member of the team would respond to the questions posted. If a developer’s question changed or was otherwise resolved prior to a response, they would update the Google Document, thus avoiding unnecessary work for the business members of the team.
This method works quite well for quick questions about schema or the legacy systems but can be lacking when discussing new features. In those cases, a conference call is probably more appropriate.
Bug Reports: Developer-to-Quality Analyst Communication
For small project teams, everything is magnified. Things have to happen faster with fewer people, so finding the right tools that support the small project team structure is critical. As with developer-to-analyst communications, Google Docs or something similar can be quite helpful in the QA process.
For larger projects, JIRA or something similar is a great tool for managing the QA process, but smaller project teams don’t have that kind of tool luxury. That’s why Google Spreadsheet fits this small project situation better than anything bigger and bulkier.
In the end, having everything on one spreadsheet speeds-up data entry and offers a more holistic view of the data—for a small project team, that’s worth its weight in gold.
The lesson to be drawn here is that there are ways to apply some of the best practices from larger project efforts to smaller projects, while not burdening smaller projects with unnecessary bureaucratic overhead. The best practice of project communications can be adopted for this purpose, and those same principles can be applied to other project management practices.
The key is looking at the current roles and communication practices of a smaller project team and asking these questions: Do the project team roles line up with the project team’s communication practices? Or, is there a practice that seems unnecessary? If so, modify or eliminate it. Remember the benefit of a small project and a smaller project team is the ability to quickly change practices to suit the needs of the team. Use this to your advantage when simplifying your small project team processes to strike the balance that makes the most sense in order to meet the ultimate goal—getting the project done.