Skip to main content

Tag: Facilitation

Using the Requirements Creation Process to Improve Project Estimates

Written by Curt Finch on . Posted in Articles. 6 Comments on Using the Requirements Creation Process to Improve Project Estimates

Estimation can be one of the most difficult parts of a project. Important questions must be asked in order to form the right figures and plans. How long will the project take? How many resources will it consume? Consultants may also ask the following question: What is the appropriate amount to bid on this project? These questions are not easy to answer at the outset when one generally has only a vague idea of what will be required throughout the project.

The good news is that there is a fairly simple way to improve project estimation and, consequently, the bidding process. Most people do not realize that the requirements creation process can lend insight into the length and scope of a project. Let me give you an example of how this method works and then explain how you can implement it within your own company.

The Story

Back in 1992, I was working for a consulting company named The Kernel Group (TKG). During this time, I was put in charge of porting Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating system. The project was to be done under a fixed bid, and consequently, we at TKG knew that estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that if Tivoli didn’t make the project hard for us in some unspecified way, we could port the million or so lines of code in about a weekend. I told him that he was nuts – that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks just to be safe. We also decided, rather smugly, not to report our padding of the schedule to evil upper management.

As a result, evil upper management drastically expanded the project bid to $325,000, and my coworker and I thought that this was a ridiculously high price. We believed that we were gouging the customer and that they would never accept it.

Yet they did accept it, and once the project began, we proceeded to discover how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but a whole lot more on top of it.

The Formula

Now our consulting company was religious about tracking employee time on a per-project basis, and so we broke every project into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. This project was no different in that respect; we broke it down into its respective phases as well.

Just before we started working on the project in question, I read a book called Practical Software Metrics for Project Management and Process Improvement by Robert B. Grady. (By the way, this is a truly fabulous book that I would highly recommend to anyone who is managing software development projects.) According to the book, one of Grady’s rules of thumb is that 6-8% of every software project is usually eaten up in the requirements/specification phase.

One of the conclusions that Grady comes to in his work is that you can use this fact to estimate total project size. In other words, if it took 60 hours to do the specification, that’s probably 6% of the job and the job will be 1000 hours. Following such logic, a six hour specification implies a 100 hour job. Since the specification always comes first in any project, you can get some pretty reliable estimates from this method alone. In fact, in my experience as both a programmer and the CEO of a software company, I have found it to be incredibly accurate and useful.

A second way to triangulate this project estimate is to ask experts in the area for their opinions – hopefully they will be better at project estimation than my coworker and I were that first time. A third way is to select an appropriate metric for estimation. For example, one could use line of code counts or function points in estimating the length and scope of software projects. For architecture projects, you might use number of pages in the drawings or square feet planned as similar analogies. Every project has some gross measure of its size that is available at the outset and can be used to plan the overall project in addition to this method I’ve described of tracking time against the earliest phases.

So back to the story. We really blew it on estimating and bidding on that first project for Tivoli, but when the next one came around, we had data on the portion of the overall project that the requirements phase had taken up. This allowed us to use Grady’s ratio to predict overall project size, and we found that on this second project, we came up with a very accurate project estimate. This worked very well for all of the subsequent fixed-cost consulting work we did for Tivoli.

Partially due to the strength of the solution and how well it ran on IBM’s AIX operating system, Tivoli was able to eventually sell their company to IBM for 743 million dollars in 1995.

For a consultancy that is doing fixed-cost projects, this concept of using the standard ratio of requirements phase to overall project length is a very powerful project estimation technique. It can eliminate erroneous bidding and its resulting costs, which is a major concern for such companies.

Accurate Bidding

Overbidding on a consulting job means that you won’t get the work in the first place, because the potential customer will give it to your competitor at a cheaper price. Underbidding, however, means you will win the deal and lose money. Neither situation is acceptable for businesses today, and yet, most consultancies do a poor job in this area. One way to make more precise bids is to use a key performance indicator, which is a tool used to measure progress towards a strategic business goal. For example, the number you want to minimize in this situation is defined by the formula [(E-A)/E], where:

E = estimated hours to complete the project
A = actual hours spent to complete the project

It is important to keep this KPI value as close to zero as possible, which indicates that you are bidding on projects more accurately.

Just tracking this number is a great first step towards better bidding, and you can get the necessary data to calculate it from any timesheet system, including a paper one. Automated timesheet systems, however, are generally even more effective in this area because they often have reports to calculate the KPI figure for you.

Improving adherence to your estimate can be difficult for some companies until they understand the ratio concept described above. An example of this is illustrated in the following diagram, which shows how the formula can work for any business. Your company’s magic number may not be 6-8% like Grady’s, but once you determine your own ratio for specification to total project length, you can use it again and again.

usingtherequirements1

Making it Work

I currently run a software company, Journyx, and I can assure you that this project estimation technique continues to be successfully employed by many of our customers to their great advantage. It is easy to implement and you can do it too. Once you do, you will start producing laser sharp estimates before you know it. And that’s a result we can all feel good about requiring.

Happy estimating!

Don’t forget to leave your comments below

Curt Finch is the CEO of Journyx. Journyx offers customers two solutions to reach the highest levels of profitability: Journyx Timesheet – a timesheet and expense management solution for the entire enterprise – and Journyx ProjectXecute – a solution that unites project and process planning with resource management. Journyx has thousands of customers worldwide and is the first and only company to establish Per Person/Per Project Profitability (P5), a proprietary process that enables customers to gather and analyze information to discover profit opportunities. Curt is an avid speaker and author, and recently published “All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource.” Curt authors a project management blog and you can follow him on Twitter.

What Can Be Done To Ensure Projects Are Successful?

Written by Cynthia Low on . Posted in Articles. 9 Comments on What Can Be Done To Ensure Projects Are Successful?

  • Projects Run into Trouble and Does Anyone Care? Leroy Ward takes a close look at the failed project situation. He reviews the findings of various research projects and offers his thoughts on what can be done.
  • Leveraging Project Portfolio Management to Implement an Effective IT Governance Strategy. With a focus on IT Keith Carlson reminds us that governance is not just about compliance but also ensuring that it has the best possible impact on business. It’s about producing value and managing risk.
  • A Second Look under the Hood of the BA/PM Position Family. In this episode of Bob Wysocki’s series of articles about the relationship between the Business Analyst and Project Manager, he takes a closer look at where they overlap.
  • The Rules of Lean Project Management; Part III. Claude Emond, just back from a trip to the Far East gets back to the blog subject he was discussing before his travels. In this issue: The Expanded Management Team.
  • Now Stop Wasting People’s Time! Wasting no time, Ilya Bogorad races to the point of his blog. In very quick order he gives us five tips to help get the job done and “stop wasting time!”
  • Managing Expectations; the Key to Your Success. In his blog, David Barrett talks about the importance of setting objectives, communicating them, and keeping an eye on the target.
  • Leadership Skills for the Technical Professional. “Over 70% of all technical professionals have to be leaders,” says Richard Lannon in his Webinar.

Along with these articles and blogs and the first of our Webinar series, you’ll find many other features in this Project Times. We hope you’ll check them out and let us know what you think. Contact us at [email protected].

What Does Your PMO Do?

Written by Mike Lecky on . Posted in Articles. 7 Comments on What Does Your PMO Do?

It’s a good idea for anyone wishing to improve their organization’s project capabilities to take stock of the PMO functions they already have. Several models for PMOs exist to help you better understand the needs of your organization and how building certain capabilities and competencies in your project office can help. There are as many PMO models as there are PMOs, so developing a specific understanding of what functions your PMO must have to best support the business is important to be successful.

One model I used to like compares various project management offices with familiar functions. For example, the project office can be viewed as a weather reporting office, reporting status information and giving insight into the health of projects. Or as a lighthouse, providing assistance to projects in the form of guidance, processes and best practices as they pass through their life cycle.

While the pictures conjured up by these comparisons are illustrative, I find they don’t hit the nail on the head when it comes to broaching the PMO as a key organizational and structural element intended to support the business. Increasingly companies, especially larger ones, are attempting to develop PMOs which integrate project and business processes.

We see this with the trend in recent years toward ‘Enterprise’ or ‘Corporate’ project management offices. These aim to address integration issues associated with the functional silos of the large organizations, or to align projects to business strategy, or to provide visibility on project spending and achieved value through various reports and dashboards. Many provide support publishing policies, procedures and guidelines. Others manage the project life cycle and integrate this to the system development life cycle, or to other key business processes linked to change and change management. Yet others fashion themselves as the center of excellence and central point of contact for the business. Still others focus only on staffing PMs or on financial reporting or vendor management.

Some try to do it all! But realistically can a single PMO do it all?

Well not unless it’s very mature. Not unless the business it supports needs it to.

Recently I’ve come across another model. It’s presented in a book titled The Complete Project Management Office Handbook, by Gerard Hill. The model in the book presents a comprehensive look at the project management office competency continuum. It presents the PMO and related functions and concepts with a pro-business slant. The book details over 20 functions and functional areas, which collectively comprise the competencies an organization may choose to support in their PMO.

What I like about Gerard Hill’s competency continuum is that it reminds us, first, that alignment of project activities to the business objectives is essential to ensuring that projects deliver value. Second, that to be successful a PMO must do a good job at whatever set of functions it performs to support the organization. And finally, these functions must help assure projects deliver that value which is required for the business to meet its objectives.

 

Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]