Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
In my team, there are two full-stack developers, one DevOps guy, a business manager, and a marketing person. We will be hiring more people soon.
Is this too early to create and implement a project management process, or should it wait until the team is bigger?
While I can't give you a specific idea about it being too early, I'd suggest strongly making sure that your team fully appreciates the concepts of agile development and also wants to have a useful process in place.
Right now I am working on a team of 4.5 (3 full stack devs, an intern, and me, the PM/BA). I wanted to get us started with the agile concept early on, because the entire point is shrinking the feedback loop.
Whether you use scrum or some other flavor of agile, having an established process helps when new people come on board, so they know what is expected of them. It's a concept explored quite readily in this book: http://www.amazon.com/Team-Geek-Software-Developers-ebook/dp/B008EKF87S/ref=sr_1_1?ie=UTF8&qid=1382398521&sr=8-1&keywords=team+geek
Basically, the faster you can establish a team culture, the stronger your team will be long term.
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:
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.
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:
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.
One of the principles of good project management is to tailor your approach to the needs of your project. Looking at it from this perspective you should always have a PM process, the question is more along the lines of how formal it needs to be for the current project.
By all means develop a culture that embraces PM, but trying to implement and enforce some process based on the size of your team will come back to bite you. Either your process will be too chaotic to handle very complex projects or will be too onerous to deal with simple projects efficiently.
To get to point B, you are going to have a process. The question really is, do you want to think it through and formally design it, with control points, rules, assignments, and expectations, or just wing it. There are benefits and costs/risks to both alternatives.
What you will likely find is your performance will be less than desired. That will trigger your desire for increased controls, then you will have your answer.
EDIT: Remember that your performance capability is driven by four enablers: people, process, tools, and governance. By sort of ignoring any one of these, you are relying on super performance from the others to make up for it. For example, if you choose to use a shovel instead of a backhoe to move 10 tons of dirt, then you are relying on the super performance of the people side of the equation to get it done. You will need more people and people physically fit. Use a backhoe and you can get it done with one or two morbidly obese individuals.
The same rule applies to process. It process will exist but it would be ad hoc, non standard, unruly, unpredictable, unrepeatable.
"Should a process be put in place?" Yes. Even with a team of two I've found that it is useful to put a process in place. To tell the truth, I put a process in place when the team size is 1 (just me). I make mistakes, and process is one of the tools I use to compensate for my fallibility.
Should the process be adjusted based on the size of the team? Yes, absolutely. The process should be adjusted based on all relevant factors.
Taking the question another way, when you add the next person to the team, will it be easier to bring them up to speed if you have a documented process? If someone on your team departs suddenly and the work has to be covered by others until a new hire is found, will you want a process? If you want to do something better next time than you did this time, you need a process.
Also recognize that this is another case of "the plan is without value, but the planning is without price". If you and your team get together to devise a process, even if that process is never consulted, the exercise of collectively designing the process will result in both team improvements and process improvements.
