Agile process - not an oxymoron?
Oftentimes, smaller businesses using extremely “agile” approaches to projects are focused on people and product, but tend to create and use basic processes as they go along. For instance, the planning phase of a small software project could be as simple as sitting down with the customer and writing some user stories, and execution phase would then be giving those user stories to developers to code. The control would consist of showing the customer intermediate releases hoping that the programmers hit the mark. Thus, a consultant could successfully complete a smaller project using this simple process while relying on their subject matter expertise and heroics, as often happens in real life. I admit, many times I went straight to coding after meeting with a customer and was quite successful doing that on multiple projects in the past.
Surprisingly or not, such approach is often advantageous to a customer, since this process is actually tailored to the customer’s needs. The customer is continuously involved in the project planning and control, allowing the project leader to judge customer satisfaction and make adjustments on the fly. The customer is also able to make suggestions and see the project deliverables taking shape, thus eliminating negative surprises.
Moreover, by skipping managerial deliverables, such as work breakdown structure or responsibility assignment matrix, altogether a in small project, a project lead could oftentimes increase efficiency by reducing management effort. This is especially useful if the project lead participates in the development herself. If the consultant is able to run the project in their head and has a highly experienced development team who know their roles, focusing on coding the project deliverables as soon as possible could be a viable and sometimes more efficient approach than traditional project management practice to completing smaller projects.
However, a project-oriented small business eventually wants to grow and be able to handle larger projects. This raises several questions. Is it viable for those agile small businesses to successfully deliver larger projects with more stakeholders involved while using ad hoc planning processes? Is it possible for a consultant and a project lead to remain “hands on”? What are the strategies a small business could use to compete for large project contracts with bigger enterprises?
Managing project stakeholders
A small project could have a single external customer who is also a project sponsor. Reporting the project progress in that case is easy, and could be as simple as sending out regular emails. This kind of reporting does not require much planning, and could be easily handled ad hoc.
But what if we increase the size of the project to where it draws significant organizational resources and has interest from several people? Suddenly, besides updating a project sponsor, a project manager has to figure out how to manage various people’s expectations and communication preferences, and negotiate resources with functional managers. Besides, how do you handle negative stakeholders, or people who are not interested in the success of your project, but who might have the power to kill it? Thus, managing stakeholders becomes an essential part of planning the project.
Adding team members
A project manager could fairly easily track three people working on a two months $50K project through regular communication with each team member. Three communication channels lead to the project manager (one to each team member). However, each of the team members also communicates with one another, increasing the number of total communication channels to six (three within a team, three with a project manager). Still, the total amount of communication that could pass through these channels is manageable and might not require any process to control it.
Let’s now look at what happens when a project manager has to communicate to six team members instead. Besides six channels leading to the project manager, there are 15 other channels between team members, bringing the total to 21. Thus, doubling the size of the team resulted in more than tripling the amount of communication channels through which more than triple amount of information could pass.
As we can see, the amount of potential information passed through team communications grows exponentially with team size. After a certain point, a project manager simply would not have enough time during the day to control progress of the project through ad hoc communication. Thus, the project manager needs to plan communication strategy within a team ahead of time, and the planning process becomes increasingly more important with a larger team size.
Controlling changes and scope
Increased number of stakeholders also requires a project leader to plan change control. With a single stakeholder-customer, all change requests would come from one source and could be dealt with immediately by the project lead. On the other hand, with multiple stakeholders, change request will come from different sources and often be in conflict with one another. Thus, a decision-making committee is often required consisting of project stakeholders and team members to approve or reject changes. Planning and communicating with such change control board further adds to the project lead’s responsibilities.
Besides the potential scope creep from change requests, the greater size of the development team could further add to unnecessary scope, since many developers love to gold plate. In software development, gold plating involves programming software features which are not a part of the official deliverables, but something a developer perceives a customer would like. Adding these unnecessary features increases project effort by time taken to develop these features and project risk by introducing greater number of potential errors.
This need to pay additional attention to controlling scope in a larger project leads to more time spent performing project management activities such as scope definition and control. A project lead would create documents such Work Breakdown Structures which allows them to break down project scope into work packages and assign those to team members. Furthermore, a control process would be implemented to ensure that all development works adheres to requirements. For example, the project lead might have to perform regular variance analysis of work products which could involve periodic technical inspection of the software. These tasks put further emphasis on project management.
Tracking time and cost
In small software projects, maintaining time and cost could be as simple as counting completed user stories alone versus time taken, thus giving us a rough estimate of the progress. Moreover, if a project lead participates in the development, they could always ballpark the progress of the manageable 1000 lines-of-code software directly from the code itself. Therefore, the project lead often relies on their technical knowledge to manage time and cost baselines.
Larger projects have more features, increasing both time and cost commitment. More tasks means more interdependencies and one late work package could potentially affect more consecutive work packages, increasing the risk of cost overruns and schedule slippage. To avoid schedule or cost disaster, a project lead would then perform regular earned value calculations to see if the project is on track. Moreover, in some cases to avoid missing important deadlines, the project lead would be required to compress the schedule which involves familiarity with techniques such as crashing or fast-tracking. Crashing involves adding resources, while fast-tracking means scheduling various activities to run simultaneously instead of sequentially. After all, can’t nine women give a birth to a baby in one month? Jokes aside, to maintain time and cost baselines in large projects, project management knowledge and experience plays a far more significant role than technical knowledge.
When thinking about risk, an inexperienced consultant might think something like can I fulfill the contract terms reasonably well?, and given self-affirmation, risk planning would stop right there. Come to think about it, this reminds me of a web project I did a long time ago. Back then, I never thought about risk and charged head on to execute projects as fast a possible. While executing the project, I had a programmer working on some back-end stuff with live data. Guess what, during one of the all-nighters at crunch time, he ran truncate queries on some crucial tables and had no backup to restore the lost data. The client was obviously furious, and I was lucky not to lose them right there. Have I brainstormed risks, I would have probably planned to do regular backups.
In any case, its obvious that large projects involve many more risks such as accidentally wiping customer data than smaller ones due to the sheer number of activities performed on the projects. Simple example, you are working from an office to meet a critical deadline for a work package going out the next morning. Your power goes out. You improvise and take your stuff and go do it at home or at a coffee shop. Now, imagine you have a large project where you have subcontractors working in three different cities and one of them gets hit by a storm. Do you send them to a coffee shop as well? Are you sure about that? If not, then brainstorming risks and coming up with mitigation strategies becomes critical to success of large projects.
Planning before doing
As we can see, a larger project involves greater focus on planning and controlling processes. Once a project is above a certain size, a project lead cannot coherently proceed ad hoc without exponentially increasing their risk of failure. Moreover, in a larger project, a project management role becomes more defined simply due to the necessity to pay more attention to planning and control processes. After a certain point, a consultant cannot be both a project manager and a developer because they simply do not have enough hours in a day to do both.
So how then can a small business or a consultant with limited resources and immature ad hoc processes compete with large enterprises with greater resources and well-defined processes for these large projects? We will consider this question in the next post.