It is important to break the required system (be it a website) down into smaller modules, not only because it helps developers know what needs to be done, but it allows estimation and tracking of each individual module (Humphrey, 1989, p. 87). There are a few different approaches to breaking down a system. The first approach I will discuss is the concept of a work breakdown structure (WBS).
A WBS represents a project as a hierarchy of deliverables, with the objective being that each deliverable can be developed independently of other deliverables by an individual or small team in a short time period (Humphrey, 1989, p.89). This hierarchy helps estimate and allocate resources, assign responsibilities as well as measure and track the project (NetMBA, 2007). Each organization uses different terminology for different levels of the hierarchy however the main point of WBS is to “partition the project into manageable chunks that can be individually planned estimated and controlled” (Chambers & Associates, 2006). An example of a WBS is given below.
To break the system down in such a manner means that developers must have an idea of the overall system. This brings up a very important aspect of project planning; how do developers know when the project will be finished? More specifically, what exactly are the exit criteria for the project? This should be negotiated with the client.
Land (2008) defines scope as “what you want to get accomplished”. More specifically, the scope is an overall definition of the product that will satisfy the gathered requirements. Given a schedule and budget, one can define scope (Land, 2008, p. 150). This relationship between schedule, cost and scope is also known as the triple constraint.
One inference from the triple constraint is that the scope (and hence exit criteria) can be determined by two other factors. The project cost and schedule are generally estimated by developers, however it isn’t uncommon for clients to set the project schedule. In that instance, only the cost need be estimated, which would then be used in conjunction with the given schedule to estimate the scope.
At Kintek, we strive to adhere to the triple constraint. Before commencing a project, we will meet with clients to gather the website requirements. We then deduce from the requirements how long we think development will take, and consequently how much it will cost. Frequently clients will have specific deadlines and budgets in mind, and so the scope is modified to suit their scheduling and cost constraints. Of course we are flexible throughout the life of the project – if a client wanted more functionality, we simply adjust the cost and schedule accordingly.
Chambers & Associates (2006). Concept: Work Breakdown Structure. Retrieved 20 October 2010, from http://www.chambers.com.au/Sample_p/wbs_cncp.htm.
Humphrey, W., S. (1989). Managing the Software Process: Addison-Wesley.
Land, S. (2008). Managing Knowledge-Based Initiatives: Strategies for Successful Deployment: Butterworth-Heinemann.
NetMBA (2007). Work Breakdown Structure. Retrieved 20 October 2010, from http://www.netmba.com/.