[IT/Web Project Initialization and Estimates]
A project starts with an idea, a vision, or an urge.
Generally this happens on the business unit side which can be within any level of an organization (business owner, CEO, a department, etc.).
The expression ‘business unit’ is only a placeholder for an entity which might be named differently in academic, scientific or military organizations.
Generally speaking: the project stakeholders or 'the client'.
Important is that ‘somebody’ comes up with an idea and wants a process to be automated, or supported by means of information technology without exactly knowing how that can be accomplished.
This idea must be propagated and expressed in a round that discusses the worthiness of the idea and the feasibility.
A project is going to be born.
Let’s step to the first and initial phase (not counting several informal brainstorming activities in or outside of your organization, etc,). Depending on the size of the organization and decision hierarchy several other pre-project activities will have taken place before the phase I will outline in the following, among them e.g. market research, budget considerations, external feasibility studies, internal approval processes, etc..
Let’s assume we are ready to start a project.
Definitions: in the following I’m speaking about the two parties: ‘client’ and ‘IT consultant’.
I defined ‘client’ further above already.
IT consultant stands for either one or more persons from internal departments (e.g. IT, Design, etc.) or from an external entity like an IT consulting company, a web development company, … whatsoever.
+++ INIT PHASE
Meeting / Discussion: This is the information presenting and gathering phase where the client side makes clear what they want and the IT consultant tries to understand.
What happens on the side of the…
Client:
- Defining GOALS
- Expressing EXPECTATIONS for the system
- Mapping out FUNCTIONALITY plus wish list
- Expressing VISIONS
IT consultant:
- Understanding of the goal, idea, and business processes
- Understanding of the ‘status quo’ as well as the ‘wish list’
- Clarifying everything that ‘has to be clarified’: asking questions*
- Throwing in experience of similar projects
- Identifying and pointing out limits
*== be informed about the client and the project before you hit the meeting! Do research (about client and competitors, if applicable) and build a question catalog with standard and specific questions. Further questions will anyway come up during the meeting. Preparation is essential for such meetings.
Who are the participants of the meeting? (may vary depending on the abstraction level of the project)
On the client side:
- Management level (sponsors)
- Main project coordinator / contact on business side
- Exemplary users
On the IT consultant side:
The consultant(s) has (have) qualifications depending on the project type (e.g. web, design, specific IT sectors, … or a mix of everything).
Competent & in charge: Send your best men and/or women!
Important part regarding all participants of such meetings is: everybody has to be competent in his/her field and has to be the ‘person in charge’ and not a substitute of the right person. Imagine when all answers to questions (regardless on which side) end up in: ‘I don’t know, I make a note, I have to ask Mr./Mrs. … and will get back to you).
It’s completely o.k. and normal that questions arise where a specialist of some type is needed or where the information has to be researched or looked up – that happens all the time among professionals, but what is meant is that: when you want to win a challenge then send your best team otherwise you’ll loose ground (here: time and money) right in the beginning.
+++ ESTIMATE PHASE
After having gathered all information and having a clear picture of what the project is about, it is time to define the exact scope of the project and give an estimate regarding costs and resources.
Defining the scope means that you have to document every single facet of the project the way you have perceived it.
That’s the ground on which your estimate lives. At the end there’s a number (in Dollar, Euro, or whatsoever) and if a client agrees to pay that price it must be 100% sure that there will be no misunderstanding regarding what will be done for the price. There’s no room for flexibility – sloppy phrases in an estimate can cost (both sides) a lot time and money. And: a good and successful project is one where both sides get happy.
Anyhow, making estimates is probably one of the most hated task because even with much experience there remains always a certain uncertainty.
The project has to be broken down in small units and tasks whereby the methods tp achieve this vary. A classic is the 'Function Point method' but in my opinion you can go 'free-style' if you like since you have to feel comfortable with the way you do it. The more you break up the project into tasks and the more you get into details the more time it takes but the better the estimate gets.
Time is unfortunately a resource that is likely to be limited but never make a quick shot when dealing with an estimate.
During the estimate process you try to figure out how long (in hours or days) it’ll take one person to finish each task unit. You always try to find an analogy to a task you or somebody you knew has already completed. The best analogy of all would be a comparable project regarding volume and complexity – that estimate would be easy but unfortunately it’s often not the case.
The definition of the expression ‘task unit’ is flexible: you can either estimate entire phases or milestones or actual programming tasks like retrieving data from a database and filling a listbox etc.. What you do depends on the actual situation but it is always a good idea to dig ‘deep’ into the possible complexity of a project to be sure you haven’t overlooked difficult tasks. During the information gathering process many tasks look easy but can take their toll later on when implemented.
An example: a paging functionality through data in a .NET GridView is simple as long as you don’t work with millions of records in your database back-end. So estimating that the implementation of the GridView takes 2 hours can be fatal when you suddenly have to figure out how to retrieve the 20 lousy records of page 250 without retrieving the entire record set and killing your performance. You will suddenly find yourself doing research on the topic and performance tests and hours will go down the drain.
After summing up the time for all project (task) units you have your first ‘number’.
Let’s assume you think it will take 1,000 hours to finish the project. When I started estimating I was told then to add the ‘buffer’ which is your ‘insurance’ against unpredictable and hidden incidents. And in most projects there will occur an unforeseen situation – either because your estimate has under-estimated a task or because hidden complexity surfaces or, or, or ….
The buffer is not instated to rip of the client ! In most instances it’ll be used what means that the overall estimate including buffer is legitimate. Think of it like to pay for a product in the supermarket where the ‘theft’ deflation is included as well.
So what is the buffer? That depends on the uncertainty you have regarding each task unit. If you are very unsure about a task it’s o.k. to add 100% up to 150% on the duration. On normal (quite known) tasks add 10-20%. Everything else is in between, more precisely around 50%. If you don’t want to do it on a task unit base then a rule of thumb says to add 50% on your overall estimate in case you’re quite satisfied with your estimate so far. If you have the feel that you really not know what to think then either pass the estimate to somebody else or add 100%.
An additional way to insure your estimate is to interview the team members who will participate in the project. After you have split up the project into task units you probably have in mind who the best team member for that will be. Take the time to have a chat with each involved team member and ask for their estimate for the task: ‘How long will it take you to do … [this task]?’ They are the people fighting at the ‘front’ and they will know best. It’s also a great way for the project lead to figure out how comfortable they are with the task.
A project leader has to have certain experience in all possible fields but is not the one who will do it later. May be some pieces but for the rest of it he/she has to trust the team.
The project lead can also get valuable insight into the strengths and weaknesses of a team member when involving him/her in the estimate process.
It would be fatal as well if you as the project leader think you could accomplish the task goal in 1 day whereas your actual team member needs 100% more time (luckily you have your buffer!).
Otherwise, in many cases your team members will solve the task faster than you (thought) because they ‘live’ in the particular topic every day and can work more efficient.
Conclusion: involve the prospective team members.
Another aspect of calculating the overall project time frame is to evaluate how much you depend on third parties. This can be another department in your company but also a provider or any other company which will be involved.
At this point you really can’t predict how things will work out and how reliable the ‘outside’ world is.
You might not have need to calculate costs for these project parts but at least it influences the finish date. Remember to reinsure your estimate by stating on which outside factors the finish date depends.
If the client doesn’t care about reasons and ‘outside’ world risks then you have to make sure that you get an insurance policy from the third parties regarding their responsibility of finishing ‘punctually’ on time.
Realism of estimates
An estimate deals with time, needed resources and resulting costs.
Flow diagrams help to visualize the project and e.g. Gantt diagrams can be used to arrange tasks and assign time units. They also provide insight into the overall REALISTIC project time frame.
To estimate time units for tasks requires to know your resources – specifically human
resources but of course technical as well. The answer to the question how much experience your staff has and additionally the correct assignment of tasks to the person that fits the role best is key to a successful project. See further above: involving the team members and having a chat with each one.
If you were honest to yourself and took off the pink sunglasses (and ignored the pressure of your management regarding keeping the estimate ‘nice’) , you will now have a realistic time frame for the project and a realistic finish date you can promise to keep without becoming a nerve wreck over the course of the project.
If you make other (unrealistic) promises you hopefully have already plan B handy. This plan B means probably to work ‘long hours’, ‘sunny weekends’, and eventually hire external resources which certainly cost a fair amount of money.
Since ‘long hours’ neither make the staff nor you happy (in case it happens on a regular basis) and emergency hiring of additional staff is not the best way, better stick to realistic estimates.
Of course, some clients insist on a fix finish date, sometimes for reasons outside their immediate control which is legitimate. Or your company wants to get the winning bid at any cost (literally).
This means you have to adapt your resources and time plan accordingly: if you made an honest and realistic estimate you CANNOT squeeze everything into a shorter time frame.
If you agree on an unrealistic finish date (utilizing your own resources) you HAVE to add further resources (e.g. out-sourcing of tasks and components or hiring staff) or shrink the project scope by negotiating a 'leaner & slimmer version of the project'– it’s that easy!
If the time frame and the costs are approved the project can begin.
+++ PROJECT MANAGEMENT in brief
Once the overall project scope is transparent the project team can be built and the project can be planned in detail.
Assuming a project leader has been determined already, this lead will set-up the project schedule including phases and tasks and will create the project team.
Ideally the project leader was already involved in the INIT phase and ESTIMATE phase because that would make sure that he/she knows the project already and can rely on the estimate.
If somebody else did the estimate and the project lead steps aboard later it remains to hope that he/she agrees with the estimate…
Relevant for the success of the project is mainly the competence of the leader, sub-leaders and the team members. If your estimate is solid and realistic the team enjoys a smooth ride.
PROJECT PHASES
CONCEPT PHASE
Organization (team, contacts, question catalogs, time frames, milestones, reporting, etc.)
Definition business rule (purpose) concept: defining 'Use Cases', 'Goals', Audience, user interfaces, etc. (supported through Logical or abstract data models)
Reviews of the conceptual part including optional prototype
SYSTEM ARCHITECTURE PHASE
Technical concept: detailed technical specification, physical data model, ... a practical guide for developers
DESIGN PHASE
For visual products like websites is the design phase a very important one. Usability and Look & Feel of the site have to be established and approved / reviewed regarding meeting business purpose concept criteria.
Design phase and system architecture phase go hand in hand and have to be synchronized. Front-end and back-end responsibilities have to be identified and limitations explored.
REALIZATION PHASE
Full implementation of the specification.
TEST PHASE
Probing test cases, sometimes documenting the procedure for later review.
PRODUCTION / RELEASE PHASE
Deploying the project on production servers, release of the system.
Involves in some cases a change management procedure or coordinating the data import from the old system. Such data migration / system migration might be a huge portion of a project or can be handled as separate project.
SUMMARY
Phases may certainly overlap and the order of phases may vary among different projects. There might be as well other phases like a marketing phase which is triggered at some point in time during the project.
Until now the documentation process of the entire project has been left unmentioned but it is of course clear that a documentation accompanies a project all the time.
Project management involves also the ongoing tracking of the project progress and this involves again an ongoing communication flow between project lead and all team members as well as the project stakeholders, a.k.a. the client.
Cheers, best regards,
Frank
(rev. 2006-Jan)