One thing that IT managers – and many managers whose work consists of projects struggle with is staff forecasting. Project work can often require elastic staff scalability. I have more projects, or bigger projects, or tighter deadlines therefore I need to increase staff (elasticity) to a larger size to complete them on schedule. As a leader, I need to have practices in place that work equally well with larger organizations as with smaller organizations (scalability).
In observing how the construction industry scales to do projects there are lessons IT can learn, but they don’t apply directly.
When a large building is under construction, the entire design of the building is “understood”, so that many “crews” can exercise “skill” concurrently to bring the project closer to completion. The crews work mostly independently, building “sections” according to their skill, collaborating only when reaching points of contact with other crews (same skill) or other skills. Collaboration at points of contact is facilitated by a site leader (foreman) who coordinates the activities of all crews and skills to maximize output, mostly by minimizing the need for collaboration.
The thing is that this minimal collaboration works for one reason and one reason only: the entire design is understood and the skill that is exercised to complete the project is repeatable and predictable. In IT, infrastructure build out often is similar to this. Standing up servers or network infrastructure or SAN or even end user platforms are repeatable and predictable. Most times (unless it an organizations first time implementing) the design of the infrastructure is understood.
Software is a little different. Programming is not a “post-design” implementation exercise of skills. Programming is the final design phase. Construction is actually done by the compiler or the build server. Software development is not very predictable, it is not very repeatable, just like the act of designing a large building is not very repeatable or predictable – why? Because we are never going to design this building again. We could build it 100 times, but the design is ever only done once.
When we think of software development, we really need to look at the architect’s workflow, rather than the tradesman’s workflow. When an Architect designs a building, he takes the requirements from the customer, and “proposes” an initial design (a straw man). He usually uses this to drive out the remainder of the requirements. He understands the building codes, the physical principles of building materials, and the construction techniques that will be used to build the building. He may iterate design ideas with his customer several times before the customer “accepts” his design. Once his customer is satisfied with the design ideas, he sets about finalizing the design – assigning out sections and trades to his assistants. The principal supervises and reviews the work of the whole design team. There is intense collaboration between team members and often daily meetings to review portions of the work as they are completed. The principal certifies the design, before submitting to the client for review and then to the municipal building department for permits.
Interestingly, the architect’s billing is usually either time and material or some multiple of the final size of the building (using size as a relative measure of complexity), depending on the project.
By analogy, software developers also get requirements from the customer. He may propose a “straw man” or actually code a proof of concept, to clarify or drive out the remainder of the requirements. He understands the enterprise coding standards, standard software architectures or stacks, and programming paradigms that will be the implementation platform for the software. He may iterate design ideas with the customer many times before the customer is comfortable that the design will be usable. Once his customer finalizes the requirements and accepts the high level design proposal, the team works on finalizing the design by detailing the layer designs and then coding the components required. Each of the components has some specification for how they behave and how they interact with other components. The team codes each component and assures its correct behavior and inter-component interaction. There is intense collaboration as different team members work to complete their assignments and meet to review portions of completed work. As the final design of some major section is completed it is “trial built” and sent to testing for certification. As each new section is added to the completed design, all completed sections are repeatedly trial built and tested until the entire complex is “code complete”. As each test reveals defects or deficiencies the design is refined and corrected to ensure correctness and quality. When the complex is code complete all components are re-tested to ensure that they have not been damaged by later design exercises.
What, I hear you ask, does this have to do with staff forecasting? Everything. You are not hiring carpenters, plumbers, electricians, roofers, painter; tradesmen. You are hiring architects, draftsmen, engineers; professionals. Your team of professionals will scale differently than a team of tradesmen. They require intense collaboration, so team formation takes longer. Their work is iterative, not linear – so much less predictable. Every project is different, so they are applying their skills to new challenges, rather than doing the same work in a different location. There is a limit to the size that the team can grow to, beyond which either the work cannot be divided, or the cost of collaboration reduces the value of the addition. The stability and repeatability of your teams practices govern the chaos, if your teams processes are stable and repeatable, then they govern the scale of the team. If they are more chaotic, then the collaboration of the individuals govern the scale of the team.
How do you handle the forecast? How do you know how soon to grow the team? How large can the team grow to before process degrades into chaos?
Any staffing forecast, must start with a work forecast. I need to understand the increasing or decreasing demand on my staff and whether I need to net increase or decrease in order to execute effectively. My models for work included effort estimates and factors for uncertainty and confidence, but for the most part, those variables did not interact with the variables that I was tracking for the capability of my staff.
My staffing model was a simple matrix with skills down the left side and months across the top. How many web developers do I need, how many dba’s how many testers, etc? That works if I am running a resource pool. That also works if I am the “active” leader of the project, which early on in my management career, I often was. As I have managed different teams and observed other managers and consulting organizations, I realize that my model didn’t contemplate the capacity of leadership or team dynamics effectively. My model reflected linear team output, with some very simple assumptions about factors that drive team output.
Staffing Variables for Dynamic Team Staffing Models
When your organizational model calls for the dynamic formation of teams, or the dynamic expansion of staff, or even the dynamic staffing of projects – there are additional variables to consider in any staffing model.
Team Formation – What is the effect of Team Formation Phase on the output of the team? On the confidence in the plan? What scale or unit do you use to measure it?
At the individual level, team formation is about commitments. Well-formed teams make and keep commitments. Individual decision rights play an important role, each team member has decision rights over their own work, within standards set by the leadership. Clearly assigning decision rights for planning, design, team practices and process within the leadership is critical. Changes in team practices move team formation backwards to prior stages. Having too much “democracy” also inhibits team formation. Team formation assumes a certain amount of stability. When there is leadership transition, or planned expansion of the team – team formation gets kicked back into the storming phase. How does the team formation phase affect your resource forecast? How long do you plan to be in each phase? What is the effect of being on each phase on the forecast?
On-boarding Time – What is the amount of time that it takes before a new developer produces independently (without being a drag on the other team members)?
Complexity of the business domain, divergence from technical patterns, familiarity with team process and practices all can increase on-boarding times. Having a well documented environment setup, having well organized documentation, and regular team collaboration can decrease on-boarding times. How do you reflect on-boarding time in your forecast? When your plan calls for adding new resources to a team, how do you account for the fact that those resources aren’t immediately productive. How do you reflect the drag on the rest of the team as they “learn”?
Talent – What is the impact of the talent of individuals on the output of the team? What scale or unit do you measure talent?
Competence – What is the impact of the lack of competence of individuals on the output of the team? What scale or unit do you measure Competence?
Competence can be thought of as the ability to repeat accomplishment with increasing certainty over time. In a prior post, I dealt with the difference between non-competence and incompetence, so What is the effect of incompetent resources on the team? Who on the team is most affected by incompetent resources? Is it a uniform drag on the team? Does it increase in effort required to lead? If it increases the effort to lead, then is it a net reduction in leadership capacity or scope?
Leadership Scope – What is the impact of the scope of your leaders on the output of the team?
Scope is an aspect of leadership talent. It describes the size (and shape?) of the team that the leader has capacity to effectively lead? How do you reflect the cost of growing a team beyond the leader(s) scope? How does your forecast reflect the aggregate scope of leadership across leaders? How does your forecast reflect the excess capacity of a leader? What is the interaction between leadership and competence?
Leadership Vision – What is the impact of the vision of your leaders on the output of the team? What is the interaction between vision and uncertainty?
Vision is an aspect of leadership talent. Someone once described it as the ability to “see around corners”. I would describe it as the ability to assess the impact of decisions at many levels of detail. Vision is the ability to see the impact of detail decisions on the whole and to comprehend the impact of high level decisions on the detailed activities of the team. Vision is the ability to identify when decisions increase or decrease risk, uncertainty, or effort, and to explain its impact to decision makers. Does proven vision of leadership increase your confidence in the face of uncertainty
—
When your software delivery organization has a stable team model, you think one way. When your software delivery organization has a dynamic team model (whether onshore, co-located, distributed, outsource, or off-shore) your thinking has to evolve to understand the demands that each of these models place on leadership, and how your team/organizational practices much support the delivery team in these models.
The more dynamic the funding, the more dynamic the staffing, the more demanding on the leadership organization.
No Comments