Project goals: Why, not How

The most important factor when starting a project is to define the goals of the project clearly. A goal doesn't have to be complex, it is often better to try to keep the description of a goal in a few lines of text, pictures or drawings. Project goals should clearly state why the project is being done, but ideally should not address the issue of how the goals should be reached. If the exact implementation method is fixed in the goal of the project, it can make the actual implementation process immensely more difficult and thus more expensive. Since Drupal, or any other system based on ready-made functionality, offers a huge variety of different possible implementation methods, it is much more sensible to approach the project from the point of view of the goals and leave the studying of more detailed ways of implementation (how) for later.

Project goals should be clear enough for entire project team to fully understand and simple enough to be used in project communication to external parties. Based on the project goals we should also be able to set criteria that will be used to measure if project is successful or not.

Requirements

In addition to goals, requirements are always a part of a project. Requirements should be binary, they can be evaluated with simple true/false and it should be clear on how to interpret them. Possible requirements could be, for example, integration of single sign-on registration or the ability to cope with usage spikes of certain amount of requests per second. It is good to divide the requirements into functional and non-functional. Functional requirements are those having a clear effect on the functionality of the system. For example, integrations, functionalities or issues relating to the visual guidelines of the website or service are functional requirements. Non-functional requirements are usually invisible to the end user unless there is a problem with them. These types of requirements are for example response times, backups, ability to do version upgrades and scalability.

When setting requirements, it is important to be exact when they can be considered as done. People also have a tendency to overdo the requirements. Keep in mind that requirements will often be part of the project contract and with a long list of requirements the project will become less and less flexible. Just list the absolutely required things and keep a separate nice to have list instead that will not be part of the contract. Also with requirements it's important to usually concentrate on what should be done and not how to do it.

When defining what should be done preciseness can and shoud be used particularly when it comes to non-functional requirements. In this case it is necessary to use figures instead of vague expressions. For example, the requirement of a system to be able to handle usage spikes of a thousand simultaneous users, is much better than to vaguely require that the system needs to cope also under a lot of traffic.

Realistic scheduling

When scheduling a project a typical bottleneck is usually found from the client organization. The single most important person in a project is the project owner. The project owner role is the business owner for the project or a proxy of the business owner (customer project manager, product owner in scrum or something similar) in some cases. Project owner is the one who prioritizes work during the project, decides on which alternative implementation paths to take and communicates with the project team daily. Scheduling a project just based on vendor resources is generally a bad idea unless key individuals from the client certainly have enough time for the project.

Project schedule should include enough time for internal beta testing and possible public beta testing. It should be kept in mind that releasing a website or service for the first time to a large audience with large amount of publicity is the most risky way of releasing. Brand new website or service has typically the greatest amount of bugs, issues and things that could have been implemented better in its whole life cycle at the time of release. Together with maximum number of flaws maximum user amounts, equals for a possible catastrophe. By organizing an early limited test release before larger release, the quality can be further improved and the outcome can still be affected based on user experience gathered. In addition to scheduling, it is important to remember to reserve enough budget to analyse the results of the limited test release and to make the necessary changes based on lessons learned.

Budgeting and request for proposals

Depending on the web project, typically 50-95% of the costs of a project for its whole life cycle come after the release. Project life cycle is discussed in more detail in a separate post later. However, budgeting done in the beginning of the project is naturally a critical factor in relation to the success of the project.

When creating a project budget most organizations have their own policies. No matter what the basic princibles are every project budget should somehow be based on the expected value generated by the project. This also means that if the size of the investment is starting to cover major part of expected value it's time to reconsider either the scope or if the project should be done at all.

When the project budget is known there are a few different ways to move forward. Usually after goals, requirements, schecule and budget is in place it is time for request for proposals (RFP) from potential suppliers.

Unfortunate in most requests for proposals customer just presents a number of goals and requirements leaving budget open with intention of saving money. This also means proposals by different vendors will be difficult to compare since they differ on scope, quality and price. Even with best RFP different people will always interpret parts of it differently leaving them with different understanding on the scope. Even if we try to lock part of quality with requirements something will most likely be left out and on top of that having a huge list of requirements it not a great thing to start the project with. Pricing is the easiest of these three to compare but it really doesn't tell us that much by itself. Fixed project bids would be easy to compare if scope and quality of offers were identical and daily/hourly rates would be easy to compare if we were comparing interchangeable units. Unfortunately in real life even two fixed bids are never identical in scope and quality and productivity per hour/day is very far from being interchangeable between two knowledge workers.

We are left with a few options: Choose the best proposal based on gut feeling, try to create fancy spreadsheets to compare suppliers on number of criteria or do some combination of these two. In real life this is a difficult process and requires a lot of experience and at least some luck from the buyer.

To make the RFP process even a bit easier it is often a good idea to set the target budget for the project and publish it in the RFP. This approach has multiple good aspects to it. First of all it offers an instant reality check by the potential suppliers where they can right away tell the customer if the budget is realistic or not. Second benefit is that the price really communicates well what sort of scope the customer is expecting for the project. Third and the biggest benefit is that all proposals will be much easier to compare when they compete only with scope and quality and even the variance in scope will be much smaller when the supplier already know the target price. Unfortunately publishing the project budget in RFP is still a rare thing to do, but it makes the process more transparent and has clear benefits to all parties.

Some would say that publishing a budget is bad for price competition between providers. Price competition can be a positive thing, but most complex projects have so many variables that comparing two proposals can be almost impossible. By eliminating the price variable it is possible to get proposals focusing on creating maximum value instead of just minimizing the cost. Hypercompetition can lead to cutting back on quality that will inevitably lead to higher lifetime cost of the project instead of any real sustainable savings.