Case Study

Case Study 1

Not-So-Efficinet Pty. Ltd.

The Problem

“Not-So-Efficient Pty. Ltd.”, an IT Consulting Company in “Not-Too-Far-Away” city have decided to update their website. They have all the right people and skillsets in their company ranging from PMs, Graphic Designers, Developers and Testers.

A team is formed and during the initial meeting the project manager asks the team if they have any idea about the “effort” involved in building a shiny, brand new website.

This type of project has never been implemented in “Not-So-Efficient Pty. Ltd.” so naturally the team don’t have a guideline to estimate the effort.

The Solution

They try to break the project down to its components and modules to put an estimate against each:
Home Page (1 X complex page)
Content Pages (15 X medium complexity pages)
About Us (1 X simple page)
Contact Us (1 X simple page)
They think a simple page takes 2 days to implement, medium 5 and complex 8 days. Adding them all up:
2 Simple Page X 2 days = 4 days
15 Medium Page X 5 = 60 days
1 Complex Page X 8 = 8 days
TOTAL: 72 days
The team adds 20% contingency on top, pushing it up to 86.4 days.

The Outcome

The Project Manager is happy and setup a meeting with the project sponsor to secure the funding for the project. Funding is approved and the team starts to design and implement the project.

The PM puts together the project plan and based on this plan the project “duration” is 50 days based on the order of tasks and the resource plan:

10 days for graphic design, 20 days implementation, 10 days of testing, 5 days of UAT and 5 days’ worth of deployment and final QA before going live.

And Problem Again!

This project in Not-So-Efficient company is setup for failure. They haven’t accounted for bug fixes, project management costs, issues coming out of UAT, service introduction, documentation and change management. And above all, all estimates are based on the “Best Guess”.

The result is project time and budget overrun, a frustrated team, lost trust and confidence on the sponsor and stakeholder part and slipped time-to-market, impacting the company and its bottom-line.

Case Study 2

Very-Efficinet Pty. Ltd.

The Problem

“Very-Efficient Pty. Ltd.”, again an IT Consulting Company in “Not-Too-Far-Away” city have decided to update their website with the exact same team structure and project specification:
Home Page (1 X complex page) / Content Pages (15 X medium complexity pages) / About Us (1 X simple page) / Contact Us (1 X simple page)

The Solution

The team decides to rely on “industry ball park estimates” to gain confidence about their estimation so after some research they subscribe to They capture the project assumptions and specifications in the ArciFrame and the system generates the summary report on the right  

At first the estimate seems to be higher than what they thought, but after going into the details they realise they haven’t actually thought about quite a few key components of the project such as Planning and Scoping, Service Introduction, Number of Environments (e.g. DEV, UAT, Pre-Prod), Team Structure (single-site / multi-site), Team skillset and so on.

  • result

The Outcome

ArciFrame has used industry best practices to come up with the estimates so the team have much more confidence in the estimated effort.
By looking at the detailed estimate and knowing the skillset of the team, the PM decides to customise the default assumptions made in ArciFrame and come up with a slightly lower effort. She saves this as a template in the system so this set of assumptions can be used in the future projects at the Very-Efficient Pty. Ltd.
The team now have a repository of “Work Items” (a.k.a tasks) so the project manager can easily create her project plan based on these Work Items. She can even export the tasks in ArciFrame and import them into her project management system such as Primavera or MS Project.

What’s Next?

Further down the track, a new requirement is defined. The website needs to get integrated with the CRM system to let the customers update their profile via the website. The Solution Architect is considering two options: Point to Point integration or implementing Web Services in the Service Bus.
ArciFrame helps him to capture these options in the system and get an understanding of the effort required for each option. The insight he gets supports him to choose the best option, considering the cost and resources required.
During or after the implementation of the project the team has a better understanding of the actual time, effort and resources spent to finish the tasks. The “Actual” effort can now get compared with the “Estimate” ArciFrame calculated in the first place so the team can now adjust the default values and assumptions in the system and save them as a template. This template can be used for the system to generate even more accurate estimates in the future projects.

But It Doesn’t Stop There..

Since ArciFrame is a team collaboration tool, team members across the organisation can collaborate with each other during the life-cycle of the projects. For instance Business Engagement or Pre-sales team can define a temporary project and capture client’s high level requirements.
The Implementation team can then capture the actual tasks required for the temporary project so the Business Engagement team will see the result and create a quote for the client based on the estimate generated in ArciFrame. This not only streamlines the collaboration between the teams and departments, but also forms a standardised and reliable process across the organisation.

Try it Free!

Free Trial