For my contribution to the Woodman Diary, which is the project we are creating for Digital Scholarly Editing, I took on the role of Project Manager. I thought I would take a few moments to discuss something that is often discussed but overlooked in any software project: project planning.
What is Project Planning?
Project Planning, as defined by Rouse, is “a discipline for stating how to complete a project within a certain timeframe, usually with defined stages, and with designated resources.”  The three components—scope, schedule, and resources—mentioned by Rouse are often referred to as the “Scope Triangle” or “Triple Constraint”. The notion of the “Scope Triangle” dictates that the scope, schedule and resources form three sides of a triangle. In the “Scope Triangle”, one of these resources is always fixed, and the other two, while flexible, move in proportion to the other. For example, if schedule is fixed—meaning the delivery date of the project cannot be changed—then if additional scope (new features) are added, more resources (also sometimes referred to as budget) must be added to accommodate the increase in scope. The “Scope Triangle” is used to ensure both the stability and the overall quality the project and its deliverables. After all, one cannot logically assume that a project, which was originally stated to take x number of months with y number of features given a budget of z, can still launch at the same time if the budget is suddenly reduced or if new features are added.
Consider this analogy. You decide to build a new home, and so you hire a company to do the work. You agree with the company that they will build a 1,000 square foot home in 6 months for €100,000. Three months into the project, you decide 1,000 square feet isn’t big enough, and you wish to add another 500 square feet to the home. Certainly you would expect it to cost more—and quite possibly take longer—than what was originally agreed to. However, for some reason, this notion often flies out the window with regard to software projects. Thus project managers are often brought in to ensure the “Scope Triangle” is adhered to, and the project remains on track with a high level of quality.
Perils & Pitfalls
Most think of project planning as creating Gantt charts and putting dates on deliverables. And while that is certainly a component, it is far from the only aspect. Below, I’ve listed some of the most common mistakes that can be made in regards to project planning:
- Thinking Too Small – project managers need to think big, and I don’t mean in regard to scope. The biggest mistake that can happen while project planning is not considering all of the possible avenues. What if we lose some of our resources due to illness or vacations? What if the server blows up, and we need to buy a new one? What if some feature we really like isn’t technically feasible? All possible avenues need to be explored during the planning phase. There is no scenario too far-fetched.
- Making Assumptions – often, we make assumptions about the projects we are working on. “The computer centre will set up that server for us.” “That feature is very easy to implement—I’ve seen it done before.” “That software is easy to customise.” The list of examples is endless. But what if the computer centre is unable to set up the server due to their own time or resource constraints? What is the software isn’t so easy to customise or is restricted due to licensing constraints? What if that feature seen elsewhere took months to build and isn’t distributed and thus must be recreated? All of these items can have a significant impact on a project and cause it to derail. Therefore, it is important to identify assumptions early on and plan accordingly. Making assumptions is not necessarily a bad thing, but failing to identify them is a major problem. If they aren’t identified, then contingency plans cannot be created.
- Failing to Identify Risks – every project has risks. Some are obvious: loss of resources due to illness, scope creep (the subtle addition of new features that, while individually seem small, cumulatively add considerable scope to a project), scheduling constraints, etc. Every project, however, has risks that are unique to the project itself. For example, while planning for the Woodman Diary, we identified a risk regarding our software implementation. At the time, we had yet to choose a software package for the diary, so there was a risk that the package we chose could have an impact on our schedule, as it could potentially be more difficult to implement that we assumed (also, for further emphasis, see above item regarding assumptions). Identifying risks early on allows the team to research mitigation tactics. In fact, not only should every risk be documented, but a mitigation plan should also be created for each risk in order to identify how likely the risk is, what its impact on the project overall could be, and how the risk will be mitigated. By doing so, the team reduces the potential number of surprises that could arise during implementation. The fewer surprises, the smoother the implementation.
- Forgetting the Goal – every software project has a sense of excitement about it. The team is creating something new and many participants want to innovate or make something that has that “wow” factor. Thus, it’s easy to get caught up in the “glitz and glamour” and forget about the goal. Whenever the team is considering adding a new feature or changing an already defined feature, the first question that should be asked is: does this change bring us closer to accomplishing the goal of the project? If the answer is “no”, then the feature should be scrapped. It doesn’t matter how “neat” the feature might be; if it doesn’t serve the goal of the project, the feature is ultimately a distraction. Of course, if the team answers that question with “What is the goal?”, then a much bigger problem exists. Before project planning even begins, a goal must be clearly set out and communicated to—and agreed on by—the team.
Project planning is a vital process of any endeavour, especially when creating or implementing software (and ultimately, every digital scholarly edition is, at its heart, a software project). It should never be ignored, lest the project fall to chaos and disarray. That said, it is important to remember that it is about more than just marking down due dates next to features and holding the project team to a schedule. Project planning is also about seeing the big picture and knowing how to respond to various situations that may arise that were unexpected. Project planning is much like warfare—considering all the various angles and developing strategies for dealing with the enemy. However, in the case of project planning, the enemy is often ourselves and our own failures to look ahead.
Kerzner, Harold R. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edition. Hoboken, NJ: Wiley & Sons. 2013. Print.
Sylvie, George, Jan LeBlanc Wicks, C. Ann Hollifield, Stephen Lacy, and Ardyth Broadrick Sohn. Media Management: A Casebook Approach. New York, NY: Taylor & Francis. 2009. Print.