Case Study: Engagement Management

Service Client on the Mechanism of Metal Cogwheels.

In medium to large organisations which are in the business of providing IT services to clients (be infrastructure, integration, management consulting or bespoke development services), one of the key activities during the pre-sales is to provide quote for the services to be delivered.

Sales or customer engagement team often reach out to the technical resources in order for them to estimate the cost and effort for provisioning of such services. The sales team then add a margin to the figures and prepare the quote for the client. Oftentimes the quote needs to be revised due to client changing the scope of work. The process above needs to be followed again (sales ask technical to provide estimate, technical do the estimate and send to sales, sales add margin and create a new quote).

Aside from inefficiencies caused by the process above, the business as a whole is in need to standardise estimates and quotes to avoid inherent issues with quoting different figures to different clients for the same services, or providing inconsistent quotes to the same client each time they ask for similar services. Despite honest effort to avoid these issues, a lot of service providers have suffered from losing credibility and trust simply because of inefficiencies and lack and process standardisation across the board.

In an attempt to address these issues ArciFrame equips service providers with collaboration capabilities as well as templates and standards so that different teams in the organisation can collaborate with each other in an efficient way to collectively estimate and quote the client. Templates are reused, and historical assumptions and estimates are stored in the system to avoid discrepancies between previous and future quotes.

See ArciFrame to learn more.

Read More

Businessman on white throwing dart with hand over eyes FOCUS ON DART

Impossible to Accurately Estimate the Effort for IT Projects?

I remember I read an article a while ago about the difference between Construction Projects and IT Projects. The similarities are obvious: in both projects it starts with a concept, then comes planning followed by design and drawing the blue print (using CAD is construction, UML in IT for example), detailed design, implementation, test and delivery.

But there’s a catch! There’s a fundamental difference between two industries – the best analogy I’ve come across (and I don’t remember where I read it so unable to mention the source here unfortunately) is that Construction is like building using Lego bricks and IT is like shaping a Play Dough.

IT is much more fluid and flexible and comes with it complexity and “uncertainty”. That’s probably why estimation in Construction is much more accurate compared to IT projects. In IT there is a lot of moving parts; these malleable moving parts can be pressed, pinched, rolled and flattened.

So estimating IT projects should be different from estimating construction projects to cater for the very nature of these projects. There have been a number of attempts to formulate the IT estimation and each has its own merits and drawbacks.

After studying and applying many of these methods, I concluded that the best approach to estimate is to “learn from the history” and customise it to your project requirements and assumptions.

So what is “Learn from the history”? There are countless of IT projects which have been implemented around the globe and there’s a good chance your project has similarity with some of them. Chances are other teams have implemented an ERP using Oracle EBS with similar scope to yours. Or there are projects similar to your upcoming “Website Facelift” initiative which have used ASP.Net with C#, WCF and SQL Server 2012 database. Or alternatively the “history” can be sourced from your previous projects with the same specification, as long as there’s one.

Estimate Cartoon


By taking the effort spent on adequate number of similar projects and average them out, we have a “ball-park” industry average we can base our project on. Obviously no two project are identical so we should be able to tweak the figures based on our Project Scope (for instance whether the requirements are defined already, types and cycles of testing, number of deployment environments, scope of user training and service introduction, etc.) as well as some Key Assumptions (e.g. size and skillset of the team, overall complexity of the project, onshore vs. off-shore team, etc.).

At ArciFrame we figured out that by following the three steps below and applying the “industry ball-parks” for similar project types on top of that we can get to a point that we have a fairly reliable estimate:

  1. Define Project Details and Assumptions
  2. Define Project Type (e.g. SAP Implementation or Android Mobile App)
  3. Define High Level Work Items

The result is an estimate which plays a key role in making strategic decisions upon the initiation or even during an IT project.

Share your thoughts and experiences here.

Read More