One way to think about project management is that it isn't necessarily about adopting a specific process, framework, or set of practices. Rather, it is most often a tool for managing expectations and making sure that project-related communications are effective.
It is never too early to manage expectations, or to start communicating effectively. The only real question is what level of formality is necessary to achieve those goals within a given organization.
The formula for determining the number of communications channels is:
n * (n - 1) / 2
The complexity of managing project communications is therefore a function of the number of people involved. For example:
- A two-person project has only one communication channel.
- Your company currently has five people involved in the project: two developers, one devops, one manager, and one marketeer. This results in 10 communications channels.
- A full Scrum Team with a Product Owner, Scrum Master, and six development team members has 28 communications channels.
You may or may not need a formal project management process at this point, but you certainly need to start thinking about an effective communications plan for your projects.
Rigor and Overhead
Small teams usually don't require the same level of rigor in their process as larger teams do. That doesn't mean controls aren't present in the process; it just means that they are often less stringently applied in order to make them less time-consuming.
The rigor of a process is typically correlated with the amount of process overhead. For example, a formal Scrum process using a two-week sprint usually consumes around 30% of available man-hours in framework overhead. In contrast, a simple communications plan where everyone on the team simply posts a status report on the wiki once a week consumes less than 3% in overhead.
The trade-off is essentially between improved communications within the organization and time spent on active development. Most projects reach a tipping point where the cost of communicating poorly or building the wrong thing is more expensive than the cost of any process overhead.
The tipping point will be different for each organization and each project, but my personal experience is that it's time to think about adding some rigor when:
- The project involves more than three people.
- The project requires a formal budget.
- The tangible or intangible cost of project failure exceeds the project's budget.
Your organization may have a different calculus for determining when it's time to formalize a project's controls, but every organization has to make the same essential trade-offs. It's probably not too early to start crunching those numbers for your organization and determining where that line should be drawn.