Perils of Project Planning

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.” [1] 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.[2] 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.


[1] Rouse, Margaret. “What is project planning?“. March 2007. Web. 19 April 2015.
[2] Jenkins, Nick. “A Project Management Primer: Basic Principles – Scope Triangle“. n.d. Web. 19 April 2015.

Further Reading

Haughey, Duncan. “Project Planning: A Step-by-Step Guide”. n.d. Web.
Kerzner, Harold R. Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edition. Hoboken, NJ: Wiley & Sons. 2013. Print.
Project Management Institute. “The Project Management Office: Aligning Strategy and Implementation“. April 2014. Web.
– – -. “The Value of Project Management. 2010. Web.
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.

Designing the Diary

We are now almost two months into the second half of Digital Scholarly Editing. The bulk of the work this semester is focused on the creation of a digital scholarly edition. We have chosen the war diary of Albert Woodman, a signaller with the Royal Engineers during the Great War. The diary itself is an interesting object; it spans two physical books and, unlike traditional diaries in which the author tends to only write a single entry per page, Mr. Woodman will often have multiple entries on a single page (presumably to conserve paper). Additionally, he often inserts newspaper clippings and other miscellany into the diary, which is not easy to represent digitally.

Representing Related Media

One of the biggest questions we had to address was, “How do we represent these miscellaneous objects digitally in a way that holds true to the spirit of their analogue representation?” Most of these objects are directly tied to a diary entry (often, Mr. Woodman makes mention of the object in question in his entry, or the object itself refers to a battle or news item he discussed in a particular entry). Showing them separately or as secondary entries in the diary breaks the metaphor of the diary itself. After all, you can’t really have two entries for the same day—that isn’t in keeping with the way a user envisions a diary to work.

Ultimately we decided to tie these items to an entry as “related media”. From an implementation standpoint, this is relatively simplistic. Within the TEI of the diary, we simply insert another <div> tag at the bottom of the <div> day which wraps that day’s entry. This <div> tag is then given a type attribute with a value of “insert”. When we run the TEI through an XSLT transformation mechanism, these “related media” divs are then extracted and added to the entry in a section on the page titled accordingly.

As to the represented model—the model that bridges the gap between the user’s mental, or expected model[1]—and the implementation, it was decided the best implementation would be to group these additional inserts (which may also include other interesting bits of media we find relevant to an entry) and provide a lightbox implementation in order to view them. The lightbox, a modal popup which presents an image in an overlay[2], has numerous advantages:

  1. It provides additional screen real estate. By loading larger versions of the image into an overlay, a thumbnail of the image can be displayed on the main screen, which has a much smaller visual footprint.
  2. It can provide increased performance. Many lightbox implementations utilise javascript and AJAX (Asyncronous Javascript And XML) to load images only when they are requested by the user. This means the image is not loaded into the DOM (Document Object Model) until the image is actually requested, thus cutting down on the amount of data that is transmitted to the user’s browser. The less data that is transmitted, the faster the page will load.
  3. It maintains the visual narrative. Every interface tells a story and the goal of every interaction should be to supplement that story. If a user clicks on an image and the page is then reloaded to display a larger view of the image on another page, the narrative is broken because the user is moved away from the page. In order to re-enter the narrative, the user must use the back button in the browser. Anything that breaks the visual narrative runs the risk of breaking the entire experience for the user and thereby decreasing the overall “stickiness” of the website.

When used properly, the lightbox can provide a strong user experience and present the designer with additional screen real estate that would otherwise be unavailable. By using a lightbox approach here, we have managed to solve the issue of the ephemeral material as well as the problems presented with its presentation.

Multiple Entries on a Single Page

The second major interaction issue we had to address was the appearance of multiple entries on a single page. In many digital scholarly editions, the transcription is presented with the original image side by side[3] [4] [5]. This allows for a direct comparison between the transcription and the original text. However, such an implementation in the Woodman Diary is confusing. Often times, an entry may begin in the middle of the page, but as we are trained to read from top to bottom, the user would immediately begin scanning the image from the top and may be confused as to why the transcription doesn’t match the image—not immediately realising the transcription begins with text half way down the “page” in the image. Multiple methods were considered for handling this unique situation:

  1. The image would not be viewable side by side with the transcription. The user would read the transcription and could click on a thumbnail of the image that would then display only the image with no transcription. This method was discarded due mainly to the expected user interaction of comparing transcription and image side by side.
  2. We would attempt to position the transcription text on the page to match its position in the image. This, however, would require quite a bit of extra encoding as we would need to encode locations of text at given pixel points within the original image. While a novel approach, it was ultimately decided this would require too much effort, given we are working with limited time and resources. Additionally, we felt it was a less aesthetically pleasing interaction.
  3. We would present multiple entries on a single day to match whatever was displayed in the related images. This idea was also discarded due to potential confusion by the user. Because the user has certain expectations in their mental model as a result of the diary metaphor, a user clicking on 25 January would expect to see one entry for 25 January. Under this model, however, they would instead receive an entry for 24 January and 25 January, which might be confusing. The break in the mental model is potentially jarring enough as to disrupt the visual narrative.

After considerable deliberation, it was decided to modify the third approach and create a hybrid. On the intial view of the diary entry, the user would see only the transcription of the entry he or she had selected. Thumbnails of the original diary page(s) would be presented, which could then be clicked and viewed in a lightbox. This lightbox would present a larger view of the image along with the transcription of that entire page. If text exists in the transcription that is not part of the entry being viewed, it would be rendered in a grey font indicating it is unrelated to the entry as a whole. As an example, if the user views an entry on 25 January, that entry begins in the middle of the page in the actual diary. When viewing that page in the lightbox, the latter half of the entry from 24 January is transcribed along with the entry for 25 January that appears on that image of the diary page. However the text for 24 January is rendered in a light grey so as to visually indicate to the user that it is unrelated to the entry being viewed, while still providing the user with the visual cue that the text he or she may be looking for in the image is not directly at the top of the image.


The Albert Woodman Diary has been an interesting project to handle. It has challenged the class as a whole to consider different ways of presenting an analogue object in a digital environment. By drawing on our own digital experiences as well as research conducted within the field of User Experience design, we have been able to overcome these challenges and present a true digital edition that adheres to the underlying metaphoric premise of the diary but without limiting the interactions by adhering to the metaphor too strictly.


[1] Cooper, Alan, Robert Reimann, and Dave Cronin. About Face 3: The Essentials of Interaction Design. Indianapolis: Wiley Publishing, 2007. Print.
[2] Adam. “Are Lightboxes Good Web Design?”. 29 January 2011. Web. 20 March 2015.
[3]Sutherland, Kathryn., et al. Jane Austen’s Fiction Manuscripts. 2015. Web. 20 March 2015.
[4] Baillot, Anne.Letters and Texts: Intellectual Berlin around 1800. 2013. Web. 20 March 2015.
[5] Schreibman, Susan, et al. The Thomas MacGreevy Archive. 2001-2004. Web. 20 March 2015.