How to Deliver a Successful Project – Part 3 – Accurate Estimates, Quoting and Proposals

Jan 12, 2013 12:03 PM, - Posted by Tommy Segoro

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

ESTIMATION AND QUOTATION

First of all, as part of this article: DOWNLOAD Proposal an Quote Document Template FOR FREE!

Now that we have documented the business requirements, the next step is to produce an estimate or quote or as I would like to call it: a proposal. In the proposal is where you document the effort required to deliver the deliverables documented in the business requirements.

This part of the project is probably the most difficult one to produce because there are so many variables that we need to think of. First of all we need to determine how many people will be required to do the project and that is not including the “personal” variables ie. what if the person is suddenly sick or having personal issues, etc.

Therefore, in this article I would like to mention few tricks and suggestions to produce an accurate estimate. This trick has worked pretty well for me.

The steps that I normally take to produce an estimate:

1. Determine who will be doing the project

Now that you have identified the deliverables and the tasks within the project, you can then choose the appropriate resource (ie. the personnel). For example: in the web development scenario normally we have someone does the HTML design and the developer doing the actual coding.

2. Sit down with the resource to discuss the effort required

Do NOT determine the hours yourself from your past experience if you are not the one doing the work! This is very important! I have dealt with many project managers that just decide the hours himself while I am the one doing the work. Just because he has managed a similar project in the past does not mean that he can quote the same amount of effort for the current one. Every project is different and we need to sit down with the actual person doing it to properly determine the effort required.

Identify the effort in hours. From hours you can then translate into days, months, etc. My base currency for effort is always in hours. This way it doesn’t matter who do the work and how many resources are required in the project, what matters is the total hours quoted. As long as at the end you don’t go over, you’re good!

Get your resources to quote the effort to do the work only excluding testing and documentation (ie. the variables). If you are doing a non-IT projects get them to quote on doing the actual work without any other variables. We will properly calculate the other variables later.

3. Identify variables in percentage

Now we are identifying the variables. In IT the variables are things like documentation and testing. In other fields I’m sure you have other different type of variables. Add these variables in percentage based on your experience.

With software development I always add 20% testing and 10% documentation. What this translates to is this:

If a project takes a total of 200 hours to complete (effort only – see point 2), testing will be 40 hours and documentation will be 20 hours on top of the 200 hours. Therefore, total estimate is: 260 hours. This has always worked very well for me.

If you are leading a non-IT projects, identify the variables in percentage then add the hours into your estimate.

4. Add project management time in percentage

Project management time is stuff like entering weekly timesheets, writing weekly project status reports and attending meetings.

I normally add 10% of the total effort hours.

5. Always add contingency – again in percentage

We always have to count for “the unexpected” and the “what if-s”. In IT this is a common case: security issue. Server on the DMZ can’t talk to the internal server. A domain trust has to be put in place. You are on site and you face this roadblock. What are you going to do? Without contingency you will eat up your project time.

I’m sure with other type of projects – from time to time – you will face the unexpected. This is where contingency time comes handy.

For me I always add 10% contingency into the estimate. So for a 200-hour project, the contingency is 20 hours.

6. Add other well-known costs such as software licenses, materials cost, etc

Then add the rest of the costs that are “well-known”. What I mean by well known is, it is easy to identify. Things like software license or material cost is easy to identify.

Put a terms and conditions that materials cost is subject to economy inflation.

CONCLUSION

So that’s my method to do a proper estimate. It has always worked 99% of the time. It’s not 100% because we don’t live in a perfect world.

Just to re-iterate, for a general IT project I will do the following:
– Effort required (in hours);
– Add 20% testing (internal testing and NOT UAT. UAT is normally a process that is done by the client hence outside your project hours);
– Add 10% project management;
– Add 10% documentation (may not be required, depending on the client. As a best practice you have to always offer documentation);
– Add 10% contingency.

For example:
A 200-hour project will be put as 300 hours in my estimate.

Then from that total hours you can then create a project plan which you break down the project into tasks and assigning resource to each task so everyone knows who is doing what and when each task is due.

How to Deliver a Successful Project – Part 4 – The Project Plan and Work Breakdown Structure (WBS)

Jan 12, 2013 8:42 AM, - Posted by Tommy Segoro

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

THE PROJECT PLAN

What is a project plan? Project plan is where you breakdown your project into tasks (similar to what you have in the business requirements document except the title of each task is shorter and more concise), assign a resource and the effort in hours.

The benefit of having a project plan is everyone has a clear idea when things are expected to due. I’ve had scenarios when my project manager suddenly expects me to demo the system to the client at a particular date while the system is not ready yet. This therefore creates pressure for me because I now have to be ready for the demo on that date. If we have a proper project plan there will be no surprises. I am bound and committed to each date on the plan.

This also applies for the client, too. A lot of the times when it comes to UAT, the client forgets and doesn’t have dedicated resources to do it. If the date is in the project plan, everyone has a clear picture of who is doing what and when things are due.

I normally use Microsoft Project to create the project plan but you can use other software or methods as you wish as long as you have the following:
– Task group title
– Task title
– Effort required (hours or days)
– Resource assigned

For example, in web design scenario I will have the following:

==

Project kick-off date: 01 Feb 2013

1 – UI Design (group)
——————————
1a) Photoshop cut-up into HTML mockup files (task)
32 hours (effort)
Joe Blog (resource)

1b) Meeting to demo mockup and to write any feedback
1 hour
Client ABC + Joe Blog

1c) Mockup implementation on CMS
40 hours
Joe Blog

ETC ETC ETC

==

Then you will have a clear picture when things are due and who is doing what.

DISCUSS ABOUT IT WITH THE STAKEHOLDERS AND TEAM MEMBERS

Have an hour meeting with your stakeholders and team members to present the project plan then ensure that your project plan is accessible by both the stakeholders and your team members. Make sure that everyone is happy with the dates. This is why it is important for you to create the project plan based on the tasks written in the business requirements document.

This way everyone is bound and committed to it. If someone says, “Oh sorry..am I meant to do that by this date?” then you can say, “Yeah man…it’s in the project plan”.

CONCLUSION

Is project plan that important? Yes it is! Let me reiterate, it is used to avoid any surprises. It ensures that everyone is committed to each  date written on the plan.

From my experience project plan is never accurate. There will always be things that happen along the way. That is OK. Again, it’s still better to have a visible plan than not having it at all. Make sure you update the project plan weekly and send notification to both the stakeholders and team members.

site_inaccessible The Jetpack server was unable to communicate with your site [HTTP 500]

Jan 12, 2013 8:24 AM, - Posted by Tommy Segoro

INTRODUCTION

I am configuring WordPress in an Windows environment and when I tried to activate the Jetpack plugins, I get the following error:

site_inaccessible
The Jetpack server was unable to communicate with your site [HTTP 500]

After troubleshooting I realise that xmlrpc.php file is not working properly. When I tried to access it via the browser it’s actually missing a function called apply_filters().

What it should say is:

XML-RPC server accepts POST requests only.

RESOLUTION

When I open XMLRPC.php file there is an include statement to this file ./wp-load.php.

In Windows we need to get rid of the “./” prefix. So change it to:

include(‘wp-load.php’);

And voila….Jetpack is now installing and activated successfully!

Hope this helps,

Tommy

How to Deliver a Successful Project – Part 2 – Start It By Defining THE Business Requirements

Jan 11, 2013 7:32 PM, - Posted by Tommy Segoro

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

START IT BY DEFINING THE BUSINESS REQUIREMENTS

First of all, as part of this article: DOWNLOAD Business Requirements Document Template FOR FREE!

Throughout my career in IT, I notice that defining the scope is the initial step that is often either missing or not done properly. Before I even go into the details, let me emphasize: A PROJECT WITHOUT A CLEAR REQUIREMENTS WILL FAIL! My definition of a successful project can be found in the first part of this series.

What is in the business requirements?
– Project definition (what it is);
– Deliverables (what the client is getting);
– In-scope and out-of-scope items (the boundary);
– The actual business requirements (how the project should run).

Let me give you an example:

I realise that in life, every activity we do is a project. For example: cycling. I love cycling and I commute to work almost everyday. For me this is a small project. How come? Think about it: Based on the definition above cycling truly fits the criteria:
– Project definition: Tommy is working at company ABC and he needs a method of transport to get to the office from home.
– Deliverables: Arriving at the office by 930am.
– In-scope items: A method of transport on road.
– Out-of-scope items: A method of transport off road (eg. air such as planes).
– The actual business requirements: Tommy does not want to spend more than $5000/year on transport costs; Tommy does not want to spend more than 1.5 hours one-way to get to the office; Tommy does not want to wake up any earlier than 7am.

You can name other scenarios such as looking for apartments or houses to rent or picking up your friends and families at the airport or planning a wedding. As long as something has a timeline: it’s a project.

From my experience, in order for me to deliver a successful project, I have to first define a clear business requirements. The idea of defining business requirements is for both parties (you as the person delivers the project, and your stakeholders) understand what you are all getting at the end and how much effort required.

I have been at many client engagements where a deadline has been set without first defining the business requirements. This is very dangerous. How do you know if you can meet the deadline without defining what is required? In the cycling example above, without me defining the requirements, I could have woken up at 4am in the morning everyday if I need to arrive by 930am and I live 100km from the office and still choose cycling as my method of transport.

It has always been human’s nature to ask this straight away: “Can you do this by this date?” or “How long is this going to take?”. In fact, it is often the question that was asked by the client. However, we as the project deliverer we need to be cautious enough to say, “Let me get back to the office and re-think about it and I’ll get back to you with the actual hours required”. NEVER mentions any dates or number of hours before you are defining the actual business requirements.

WHAT IF THE CLIENT DOESN’T KNOW WHAT THEY WANT?

Scoping or defining the business requirements are also often difficult. Sometimes when the project is so big, client is confused himself  (ie. doesn’t know where to start). The way to deal with this scenario is by YOU (as the project deliverer) defining the scope for them.

For example, I’m helping out my mom looking for cars to buy. Initially my mom wouldn’t know what car she wants. Me as the project deliverer would define the scope for her by asking, “OK I’ll start with this question: Do you want a car with sunroof?”. She may say, “No, I don’t”. Then that’s THE scope. I will say to her, “OK for the first phase of the project, I will make you a list of ALL cars that don’t have sunroof. It will take me 3 days to write up the list. Let’s just do this first then we can talk about the next phases”.

See, it’s all clear! The client (mom) knows exactly what she is getting, you as the project deliverer has a clear scope of delivery.

In IT for example, let’s say you are about to begin an Intranet project and the client doesn’t know what they want. He/she may say, “I really don’t know what I’m looking for in an Intranet”. That is OK, let’s define a scope for them. I’ll say this to them, “OK, what I will do, let me create a homepage and a content page. I will choose the colours and designs based on your logo and branding. Then I will present this to you and we’ll go from there. How about that? This will be our pilot project and it will take me about 1 week to do it”.

There you are! That’s your scope, deliverables and business requirements.

You just keep doing the same for every phase of the project.

CONCLUSION

Never, ever starts a project without a clear scope, deliverables and business requirements. Your project is only doomed to fail if this is the case. Without a clear scope and requirements, you will find a lot of scope-creeps (ie. out-of-scope items that are introduced along the way) which will eat a lot of your project time. I will talk more about this in the next series.

August 2012 Cumulative Updates Bugs – Site Timeout & Navigation Items Multiplied to Hundreds and Thousands

Jan 11, 2013 10:09 AM, - Posted by Tommy Segoro

Hi everyone, just thought of letting you know that since the install of August 2012 Cumulative Updates for SharePoint Server 2010, a new bug is introduced.

This has been verified by Microsoft themselves. I am currently working with a particular client to resolve the issues.

Basically the issues are: site is suddenly inaccessible. It’s pretty much timing out. The main cause of this issue is, somehow SharePoint navigation links are out-of-sudden multiplied. This happens on a site that uses Collaboration Portal or Publishing Site template.

TEMPORARY RESOLUTION

Un-publish ALL publishing pages on the site. Make them draft. DO NOT publish any of the pages.

Then using either C# or PowerShell, delete ALL navigation items.

Once you’ve done this the site should be back up and running again.