Be the winner of $600 worth of ArciFrame subscription in return for 2 minutes of your time!

As part of our next wave of new features and enhancements to (IT Project Estimation Tool on the Cloud), we are running a very short survey and we kindly ask IT professionals to participate in this campaign. It only takes 1-2 minutes!

In return for your valuable time, we give-away 12-month free subscription of ArciFrame to 3 participants and their teams, worth $600 each! Winners will be chosen randomly by computer and announced here. They’ll receive their subscription details via email.

By sending this survey to your team-mates you’ll increase your chance to win one of the free subscriptions which you can use and share within your team.

Please click below to participate:

Read More

Can I Get a “Takes-away, Large, Double-shot, Decaf, Three Quarter Soy Milk, Extra Hot Flat White Coffee with 3 Sugars” Please?!


Over-customisation? Sounds familiar? Surely it’s one of the most common architectural anti-patterns.

I have seen too many smart project teams who start with the notion of “achieve the must-haves and quick-wins first“, only to find themselves falling into the trap of over-customisation in the middle of the project and by the time they realise it it’s probably too late to roll back or course-correct.

In case of an OOTB (Out Of The Box), it’s likely because the product they’ve chosen has not been the “fit for purpose” for the requirements, or even if it was originally, scope-creep and new requirements have led the team to try to over-stretch and “bastardise” it to make it fit for purpose. Most of the times it’s a failed attempt because the product had not originally been designed to address these stretching requirements. It’s like buying a Porche Carrera 911 as you reached your mid-life crisis, and after a month or two your friends try to convince you to join them in an off-road dirt track adventure; it’s too attractive to be turned down but since you have spent most of your capital on your beloved GT car but can’t also miss this adventure, you try to add an extra axle and lift up the suspension to make it more like an SUV!!


Here’s some quick and seemingly obvious things to consider to avoid this pitfall:

  • Do your homework before choosing the product. Study market research reports such as Gartner Magic Quadrants, reach out to other clients having the same problem and find out what they ended up choosing, talk to the vendors and draw a matrix to compare different products against your requirements. Ask for a demo and include your end-users to see the product before investing in it.
  • It’s unlikely that any given product is 100% fit for purpose. Can you compromise? Does your short-listed product address most of your “must-haves”? If so, stick to the current product features and avoid over-customisation in order to address less important requirements.
  • During the implementation, if new emerging requirements, no matter how much they’re related to the existing ones, are not addressed by the product, chances are over customising the product wouldn’t address them either. Look for add-ons and other products by the same or other vendors. If there’s no native add-on, think how you can achieve a seamless user experience by integrating two systems.

Read More

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


Bottom Line: How Much Does It Cost Me?!

IT project teams are frequently asked by project sponsors / directors to scope a new piece of work; being a brand new project, increasing the scope or adding a new module to the existing system or replacing a legacy system. There are often a lot of unknowns and ambiguities, making scoping and estimation less than a straightforward task. More often than not the project team makes a few assumptions about the modules, tasks and steps required but it always comes down to the “effort” or “cost” which is in fact the most difficult part of the estimation, and in most cases this part is what the project sponsor is interested in the most!

Best practices and experience from other projects with similar scope and specification would make this process much more streamlined and more importantly makes the estimation more accurate.

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