Connect@OnGraph

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.

Well, with the start of this blog what could have been a better post other than starting to tell some interesting stories about how OnGraph started.

I graduated from IIT Roorkee back in 2000 and joined Trilogy in Austin, USA. Probably it was the best decision of my professional life, because thats where it all started. Trilogy is my first (and the last!) company I worked for, before I started OnGraph Technologies.

We were a group of 20 Computer Science graduates, hired from all over IITs to go to Austin and attend a very unique-in-itself, innovative and intensive training bootcamp called Trilogy University (aka TU). TU gave me an opportunity to learn tonnes of technologies in a short period of 3 months. It gave a platform to expand your horizons and start thinking beyond. TU has an interesting phase where every attendee is supposed to present an idea of their own, go-whacky ideas, crazy ideas, stupid ideas, money-making ideas, money-burning ideas, you know what I am talking about now :-). I never got an opportunity to present my ideas to our CEO in TU, because my ideas were so so stupid :-). TU is managed and lead by Section Leads (SLs), who have a proven track record of success within the company . Mentioning this since it is relevant to our story. So keep reading.

I came out as a Star on technology axis but miserably failed on the axis of business ideas and innovation. Well, what do you expect out of a graduate who came out of college 3 months back, who tasted alcohol only 1 month back (look out for another interesting story on this topic) and who got lots of culture shocks from the day he stepped into America (another story here to look out for). The fact was TU actually expected a lot out from us and thats where it made many of us realize and discover the potential.

We were hired to start the offshore development center for Trilogy in Bangalore. We graduated out of TU, came back to Bangalore and started the development center. I worked in Trilogy Bangalore for almost 5 years and was a successful developer, senior developer, delivery manager, product manager and technical architect. It came 2005 and thats when I was offered to become a Section Lead for TU2005 (well you have started to see the relevance now).

During TU2k5, I worked with Joe Liemandt (Founder and CEO, Trilogy) and Steve Bell (Founder and CEO, Shangby. Was VP of Product Development in Trilogy in 2005) directly. I would always be thankful to Joe and Steve, it was because of their direct mentorship and guidance that I gained the spark of enterpreneurship. I came out as a very successful Section Lead out of TU2k5. I presented lots of stupid ideas and a few interesting ones to Joe and Steve (finally!!). I lead YourBillBuddy project in TU, and got it funded by Joe. It is a very innovative and successfull service running, targeted towards Indian mobile phone users. I lead few other projects targeted towards automotive market in India and China and they formed basis for some new business units in Trilogy.

The day TU2K5 ended, I already knew what I wanted to do next. It was to start a company where we will nurture innovation, connect the best minds of industry, become a delivery organization which will guarantee 100% customer success, build an All-Star team known for providing best-in-league technology solutions, and build a group which would create innovative products touching the lives of millions all across the world. And ofcourse, a company which would make lots and loads of money, for itself and for its people !!

I moved out of Trilogy in 2006 end after an year, moved to UK and started OnGraph. It has been almost an year and we are growing since then. We started our off-shore development center in Noida, India. We are continually adding to our list of clients, who are 100% successful and have developed trust in us. We are continously building long-term relationships with all our clients. We are looking at launching a couple of services of our own, targeted towards local and international market in 2008. We are profitable and we plan to grow more in terms of our engineering talent in India.

There are very few bootstrap startups who have the privilege of enjoying all what we have achieved in last 1 year. I want to take this opportunity to thank everyone who is part of group at OnGraph and who are putting their full energy and dedication to take it further and make OnGraph a brand that everyone in the world knows about!

Our Clients? (Coming Soon!)

Our first product? (Coming Soon!)