Connect@OnGraph

One of our best practice articles was picked up by www.pmhut.com and published on their public site.

http://www.pmhut.com/how-to-estimate-better-part-1

One of our best practices post has been published on EzineArticles

Good going!!

Try doing this little interesting exercise in a group when you are looking for some fun. Estimate how long would it take to visit all tourist spots in London. Assume that everyone has enough money and only public transport is allowed. Take 2 minutes for estimation and 10 minutes for discussion in the group to revise your individual estimates.

You can do this exercise and come back later to read this further :-), but I can tell you the result right away.

If you are 5 people in the group, you will get 5 different answers! If you ask 1 person to estimate the same task at 5 different times, you will get 5 different answers. Interesting, isnt it?

Well, lets accept it. Estimation is a hard exercise and if you master it, its one real skill. Good estimation results in better decision making and effective planning. Bad estimation results in poor planning and project failures.

Here at OnGraph, we follow a proven defined process for estimation of projects, in order to give an accurate and upfront picture to our clients, for better planning and execution at the technology level and downstream business level.

In this post, I am trying to summarize our practices and cover what actually does an estimate mean, different components of an estimate, different types of estimates, root causes of poor estimation. Part 2 of this post would cover various stanard estimation tools and practices, how to prepare an estimate and how to use those estimates effectively.

What Should Your Estimate Look Like

- For software industry, there are 2 types really.

Duration estimate - how much time would it take to build this software application
Effort or Cost estimate - how many $$ need to be spent to build this software application

- Your estimate should NOT a number. It should be a range of numbers with a probabilistic factor associated

- Your estimate should always include estimation method employed

- Your estimate should always declare associated risks and assumptions

Classic Examples
- The Good : “Building this automated tool would take between 100 to 140 hours of coding, and 4 to 6 weeks of effort. This assumes that the class design and database schema is already frozen. The time/effort would shoot up if the requirements document is not completed 1 week before the development activity can start”. Wow, you got the job!

- The Bad : “Building this automated tool would take around 120 hours of coding and around 6 weeks of effort. There may be some minor slippage in the above estimate depending on how things go”. Hmmm, may be you should see us next time!

- The Ugly : “Building this automated tool would take 100 hours of coding and 4.2 weeks of effort. No problems, we will do it”. Ahem, do we know you? Who let you in?

Components Of Your Estimate
- Always give a range of numbers, that can bound your estimate

- If possible, attach a probability statement to indicate your confidence from statistics perspective

- Give a basis for your estimation, that can justify your figures

- Always mention the associated risks and assumptions to cover up for unknowns

Basis Of Estimation And Types Of Estimation
- Use your historical data, experience data or analysis data to prove the validity of your estimate

- Most of the times, your estimates would be based on data collected while doing similar effort or tasks

- Give a Rough Order of Magnitude (ROMEst) estimate when you are in scoping phase of a project. This should just be used to determine feasibility of the project

- Give a Budgetry Estimate (BEst) when you are in project initiation phase. This should be based on requirements and work breakdown structure for the project

- Give a Detailed estimate (DEst) prepared for each iterative cycle of development for a project. This should be based on complete approved requirements and micro level work break down structure for the project

- ROMEst is wider and least accurate, BEst is narrower and more accurate, DEst is narrowest and most accurate.

Benefits Of Good Estimation
- You gain predicatibility. You can see clealry whats coming in the project.

- You gain repeatibility. You know that you can only do better next time and not worse

- You gain credibility. Your clients are happy because you mostly deliver on time. Your organization is happy because you always do right planning

- You gain strong position to drive results since you know what is going to be delivered when

- You gain a better decision making power. That helps you in almost every sphere of life.

Causes Of Poor Estimation
- We fail to follow a proven and defined process. We know the process but we get lazy in following the process

- We suffer due to lack of requirements or ambigous requirements

- We fail to bring the assumptions and risks upfront

- We fail to manage sufficient resources and sufficient time

- We fail to take hidden factors into consideration, like ramp-up time, learning curves, skill development, productive time.

Summary
- Your estimate should not be a mere number

- Your estimate should be a probability statement

- Your estimate should be made more objective rather than subjective

- Your estimate should be made more consistent and easier to understand

- A good estimate is possible only by follwing a process consistently and using your own historical data

In a global delivery environment where teams sit oceans apart, email becomes pretty much the heart and soul of effective day-to-day internal and external communication. It is very important for teams and individuals to understand that writing effective emails is actually a skill that helps in almost every sphere of professional life.

We at OnGraph Technologies emphasize a lot on effective communication skills and have developed a practice which ensures that there is no communication gap between the development team and clients/customers based out of different geographies.

Below are the quick tips and tricks to help one develop this very important skill :-

1. Always start with a strong and relevant subject line. Your first impression is your last impression.

The Good: “design freeze date confirmation query”
The Bad: “a query”
The Ugly: “hi!”

2. Always think about who is your audience and accordingly furnish the appropriate level of details

The Good: “Hi Anne, since you are the lead developer on this project, can you point me to the right location in source control for the master design document?”
The Bad: “Hi Anne, I cannot cannot the lead developer on the project but I need the master design document. Can you please send it across to me?
The Ugly: “Hi Anne, can you send me master design document?”

3. Your first paragraph should always contain the critical and most important part of your email

4. Always ask for execution action, put your ‘Whats’ and the ‘Whens’ clearly

The Good: “Hi Anne, we have a client presentation this Thursday. If you have not sent the sales data summary, please do so by end of day today”
The Bad: “Hi Anne, we should discuss about how to improve the formulae to calculate data more quickly. I was not happy with the turnaround time last week.
Lets discuss this in the next meeting. Also, please send the last week sales data. We have a client presentation this Thursday.”
The Ugly: “Hi Anne, we should discuss about how to improve the formulae to calculate data more quickly. I was not happy with the turnaround time last week. Lets discuss this in the next meeting.
P.S. We have a client meeting this Thursday. Please send the sales data by end of day today”

5. Use paragraphs and bullet points to illustrate your point, if your email is more than 100 words

6. Always add a ‘Summary’ at the top or bottom of email, if your email takes more than few minutes to be read

5. Check your spellings. Check your grammer.
Spell-checker is not an overhead but a friend most of the times. This becomes even more important when you are sending emails to clients and customers directly

6. Always give your email a quick read again after you finish.

95% times, you would like to change something in your email to make it better, if you do a quick read by yourself.

If you are a technology startup, we believe that there are few basic things that you need to have in place if you want to be a successful delivery organization. Most of the startups cannot afford to or rather would not like to setup a dedicated IT support or process-management staff.

At OnGraph, we thought about what are the core key metrics so as to help us evaluate any process or tool or methodology before we can invest any time or effort or capital, to adopt it as part of our delivery practice. We came up with the following simple metrics :-

• Quick to implement or incorporate

• No maintainance overheads

• Open Source or Free or Community Driven

• Promotes or augments Agile Development Methodology

Below are the top 10 tools/processes/frameworks/systems that we at OnGraph have adopted based on above metrics and that we recommend to every technology group. We have been very efficient in our delivery methodology and our clients are loving our way of doing things since its bringing to them what they really want, 100% success for their businesses.

• Google Enterprise Solutions for Email

• Subversion for Source Code Management (if you are a technology company)
  

• Bugzilla for Issue Management and Tracking
  

• Google Docs for collaborative editing and publishing

• Google Calendar for event collaboration

• TeamViewer for collaborative debugging or screen sharing

• Skype for cross-geography communication

• CruiseControl for Continous Integration (if you are a technology company)
  

• GNUCash for accounting and invoice management

• Kimai for Time Tracking

We provide process consulting to small and medium enterprises based on our proven stack, who wish to set up a machinery which works to let businesses focus on their core competencies rather than struggling with efficiency and productivity issues. Please contact us at sales@ongraph.com if you have any enquiries.