David Turner

Having a Plan

Major projects are rather a lot of work. Whilst I'm sure that everyone reading this is already well aware of the truth behind this statement. When it comes to dealing with a lot of work, there is one thing that stands out as being highly important. Having a plan. This post is going to outline the thoughts I've had regarding this and to help me organise my thoughts to come up with a plan of attack for my project.

Sorting things out

I already know what I'm going to do, but what does it all equate to? Without measurable goals and aims, how can I determine if I've been successful in what I am setting out to do? What do I want my project to do? The project I've settled on is one I've been thinking of using for a while now. The following is an expanded list of goals I am aiming to achieve by the end of the year:

  • Wide scope of use
    • Website referencing initially, but aiming to expand into other areas as project develops
      • Starting with print, and going from there
  • Easy to use
    • Cutting out the middleman, you don't need to go to the app, the app will come to you
      • JavaScript Bookmarklet (designed to work cross-browser)
      • Possible expansion into browser specific extensions (for better integration with browsers)
    • Records of references stored in an account, so your data is available to you wherever you go.
  • Usable everywhere
    • Aim to support multiple reference methods
      • Starting with Harvard Referencing
      • Expanding into other methods (starting with APA)
  • Make data accessible
    • Provide a clean, appealing, site that helps users get what they need
    • Focus on user data, helping them reference material quickly and easily
      • Make it easy to access this data later

As you can see, there's quite the list of, well, stuff there that I want to do with this site. Reading down the list I can already see that it's in no specific order with regards to how I'm going to approach implementation of the aspects of the project. This is evidenced by the repeated mentioning of "expanding" into other areas, so clearly this isn't anything even close to a plan of action. Let's see what we can do to help clear things up shall we?

To Do Lists

To Do

To do lists are great. They make it nice and easy to work out what it is you want to do. I know that what I want to do isn't going to fall into place overnight and that some things will take a higher priority over other aspects of the project. As a result I think that rather than have one big list, as above, it would be infinitely better to break the project into more manageable chunks or, to word it slightly more elegantly, Phases.

Phase #1 - Research

The first phase is more of a research stage, used to help me scope out what is already there because, quite simply, it would be foolish not to see what is out there. I'll also be using this as an opportunity to let me look at sites not related to referencing, as sometimes ideas can (and already have in my case) be found in sites completely unrelated to the area you're looking in. It also includes experimentation which, if you've been following my work of late, you'll have already encountered to some small extent. At this point this phase looks like:

  • Identify pre-existing products
  • Explore unrelated avenues for ideas
  • Identify why my project is worthwhile

At this stage a lot of this kind of material has already been looked into and explored. I'm covering it here to provide an insight into the process I'm following with regards to my project. I should have a post up early next week covering the details of this phase.

Phase #2 - Identification

After having looked at what is already out there, phase #2 is dedicated to laying out the groundwork that will make up the following phases. Parts of this are common sense, breaking down the list up above into sequential, smaller, parts that make it easier to implement the different aspects of my project. After all there's no point in creating a reference submission form without having done your homework on what exactly is required for the whole thing to work. This means that phase #2 is broken down into the following three elements:

  1. Identify User Requirements
  2. Identify Project Requirements
  3. Break Requirements down into manageable chunks
    • Includes ensuring that they are ordered in a fashion that actually makes sense and works.

This phase allows me to organise my thoughts and formulate a plan of action. This will allow me to work through the different elements of the project. It also provides a method to measure progress and helps ensure that I am never left wondering what needs to be done. In addition I will also be able to dedicate time only to the matters at hand, without worrying about missing out something important.

Phase #3 - Components (Agile Computing)

Phase #3 is a weird phase, as it's a recurring phase. This phase allows me to work my way through all of the areas identified in the previous stage, one at a time, to produce completed elements of my project. This is useful in terms of testing and development, as it is easier to both develop and test small parts of a solution as opposed to creating a big mess of code and being confused as to what is breaking and why.

Piecing together smaller elements of code also provides speedier completion as I can focus on single aspects that I can then complete both quickly and efficiently and test thoroughly before moving on to another aspect of the project. Each piece will also be ready to implement before the next piece is started. This, of course, leaves me with a series of pieces in a puzzle that need to be assembled. Which leads me nicely onto...

Phase #4 - Piecing it all together

Tetris Mural by calamity_sal

Tetris Mural by calamity_sal 1

This phase is similar to a game of Tetris or a jigsaw puzzle. At this point I will have a series of pieces that need to be slotted together in as efficient a manner as possible to create a complete product. I have had experience with this in the past, working for clients as well as working on my own CMS packages (one of which is still being developed and powers this blog). As such I anticipate this being a rather easy phase for me.

Phase #5 - Monitor, Review, Improve


By this stage I will have a complete product. It should do what it does very well, being both quick and secure, but you can never rule out the ability of the user to break something you hadn't though of. This is why monitoring things is important, to ensure that things don't break and, if they do, to fix them and then ensure that the cause is identified and resolved. There's no point in fixing something if you don't prevent it from happening again.


Reviewing is useful to ensure that you have made a product that matches up with what your users want to use. It could be that some users would prefer things to work differently and this might need to be implemented into the product.


Just because a product has met it's original goals doesn't mean that it cannot be improved or expanded on. You can see in my original list that there is a list of things to do and that it also includes things to do at a later date. The initial focus of my project is to provide an easy way to quote and reference online materials, but I want it to be capable of so much more. Once I have laid out a solid groundwork that I can use this will afford me an ideal platform to expand into referencing material from other mediums.

  1. calamity_sal, (2010), tetris mural [ONLINE]. Available at: http://www.flickr.com/photos/calamity_sal/5010275286/ [Accessed 08 October 10].