Project estimation for eZ Publish – part 1 of 2

Ever since I started working with eZ Publish in 2002, I have had to make numerous project estimates/quotes, ranging from projects that involved template development or extension development only, to projects that required setting up complex community websites. Essentially, the estimate serves to answer a client's two main questions: what will the project cost and when will it be ready? As a developer, consultant or software provider, you need to deal with two issues: how do you define the scope of the project, and how do you make an accurate estimate of the time required for that project?

Both questions will be dealt with in separate blog posts. This first blog post deals with the definition of the scope of the project. By the way, these blog posts are not meant as tutorials, but to gather your feedback/suggestions on how to make an estimate for eZ Publish projects even more accurate.

Defining the scope of an eZ Publish project

Defining the scope of an eZ Publish project, especially projects that involve setting up a complete website, can be quite challenging. The default installation of eZ Publish has a lot of functionality available, especially if you also include the ezwebin and ezflow extensions. And although you might intend to use only a specific subset of those functions for the project, inexperienced clients may come to expect that they will get a fully customized eZ Publish site. Because it is not easy to limit the subset of visible functionality in a default installation of eZ Publish, it becomes very important to manage user expectations regarding the scope of the project.

Scope definition by means of wireframes
 Most clients will use some form of wireframes, a visual guide that represents the skeletal framework of the website. One way to narrow down the scope of the project is to agree with the client that only all development work has to be related to specific wireframes. You could split up the proposed sitemap in subtrees and specify per level of each subtree which eZ Publish templates are used. For example, the overall site structure could consist of “1. products”, “2. services” and “3. support”. The subtree “products” could have 3 sublevels: “1.1 all products”, “1.2 product xyz” and “1.3 product specifications”. The matching eZ Publish templates for these sublevels could be “folder.tpl”, “product.tpl” and “specifications.tpl”. Each template and its template elements are subsequently defined in additional wireframes, as well as the navigation and containers. If you use standard naming conventions and number items consistently, it is easy to see what is used where.

Scope definition by means of content classes
 In projects where the budget for a technical intake/writing specifications is limited, you could also opt to use content class definitions to limit the scope of the project. Basically you agree with the customer that the CMS will consist of a number of predefined content classes, such as ‘article’, ‘blog post’, ‘products’, etc. All content classes and their attributes, settings, etc. are documented in a spreadsheet. The scope of the product is primarily defined as the implementation of these classes, e.g.: the CMS allows display, editing and removal of content items belonging to the specified content classes. That basically defines the work as the setup of content classes and the development of templates required for the display of these classes, e.g. ‘full.tpl’, ‘line.tpl’, ‘listitem.tpl’, ‘edit.tpl’, etc. Any additional functionality will have to be explicitly added to the list of available functionality. These could be functions like “search”, “rss”, “workflow”, etc.

In an ideal world, you should of course use both wireframes and content class definitions to limit the scope of the project. I am aware that these two approaches are not really specific to eZ Publish, and that there are many other ways to define the scope of a project. What methods have you used for eZ Publish projects? What do you recommend? I’m looking forward to your feedback!