Tag: Enterprise

A Blog of a Different Color – Enterprise Analysis

The collectible series continues with the Enterprise Analysis (only three more to go!). Errata pointed out by gentle readers will be reported as found (if found!). You can get a legend to help read these diagrams by grabbing the first issue of this series, if you haven’t already.

Please NOTE:  To provide proper context, it might be useful to look back at the “Initiation” installment of this series.  How DOES BA begin?

Here we go!

Click on the images for an enhanced view!

004_small 014_small
015_small 016_small
017_small 018_small
019_small 020_small

Don’t forget to leave your comments below.

Overcoming Resistance to Enterprise Architecture


Justifying the expense and effort of complete enterprise architecture (EA) modeling.


From the earliest days of systems development, documentation is usually seen as an overhead and sometimes, an afterthought. In the early days, there were even efforts to have “Self-documenting” code. So much for the short-changed analysis and design efforts.

Today, this attitude has carried forward to higher levels of systems and business planning. Enterprise architecture projects often fall victim to the same approach as early documentation. As it is eloquently described in Business Enterprise Architecture (1), the perception of the architecture and its documents needs to be changed from one of expense and overhead, to one of investment in a reusable planning “asset.” The practical, usable enterprise architecture model is exactly that, a reusable asset that should be the foundation of all enterprise planning.

Repository of Enterprise Knowledge

As noted in Working Knowledge (2), only a small percentage of current corporations have made headway in capturing their knowledge in a useful fashion. To capture all the facets of an enterprise for a complete enterprise model is certainly more of an undertaking than many organizations is willing to do, unless mandated to do so. Even those that have made strides in this area, have a difficult time quantifying the value and return on the investment. Some notable examples can be found in customer service support systems such as Hewlett-Packard’s Electronic Sales Partner and in collaboration such as BP’s Virtual Teamwork. These are respected internally as very successful systems, but yet the value of that success is difficult to quantify.

As Davenport & Prusak point out in Working Knowledge (2), any successful knowledge project must show the following nine factors to be perceived a success.

  • A knowledge oriented culture (shared knowledge versus just performance)
  • Technical and organizational infrastructure to support the effort
  • Senior management support
  • A defined link to the economics or industry value
  • An element of process orientation (distinguishing knowledge from information or data)
  • Clarity of vision and a common language
  • Nontrivial motivations for use and contribution
  • Some level of existing knowledge structure
  • Multiple channels for knowledge transfer

Resistance is Futile and the Resistance is Us

The most common examples of enterprise architectures are in government agencies. Why, because they have been mandated to have a documented architecture for budget planning. Even there, however, you will find many examples where the enterprise architecture scope has been short-changed. Where it may meet the basics for the mandate, but fall far short of being the living, planning model that is should be. In some agencies, the models are so high level as to be meaningless. Perhaps these are a good start, but they are not done to the level of being useful planning assets.

The difficulty of any knowledge based EA is to have firmly identified goals, and a realistic timeline for producing it. Keep in mind that the purpose of an EA is embodied in its title: “Enterprise.” If the scope is too limited, you lose the value of the model for planning. You won’t see the “Big Picture” bottlenecks and redundancies. If the scope is too big, you run the risk of losing management support before delivering a useful product. It’s always a balancing act between these concerns.

A Balanced Enterprise Architecture Project

Most EA projects start off with one of the common frameworks in one hand and good intentions in the other; A little management support and some existing infrastructure within which to work. The work will use this infrastructure not only to develop the models, but to make them available for use to the enterprise. Regardless of the framework that you choose (Zachman, DoDAF, UML or one of the proprietary ones,) keep in mind that most of the developed products will not be user friendly to the audience that you are building them for. Right from the beginning, an element of education is necessary for management and expected users.

First, set the expectations for management. Don’t embark on EA modeling only to be cut off when management doesn’t see the progress. Set those expectations from the outset. Make sure the scope if big enough to be useful, but plan to deliver some interim products to demonstrate progress and value. Make the architecture visible from the earliest possible point. Put out browser friendly pieces of the model for users to begin exploring. Get them used to finding and refining their own processes from the models. Let them informally view and refine the models for you. The feedback is usually very effective.

Consider how you are going to make the architecture available to the end users. Most of the current tools will generate nice HTML menus and screens, but it’s still up to the project to educate the users on how to use these for planning and knowledge search. A map of information exchanges or a process flow may not be self-explanatory to your audience. Hold some walkthroughs just to confirm pieces of the models. Leading them through examples from your organization will be vastly more useful (and better received) than sending out some documents for comment or validation. Start early to make the EA a living document and show how it can be used in everyday planning.

Solicit Ownership

From the very outset of an enterprise architecture project, you need to set the expectations and solicit ownership from every corner of the organization. Don’t allow the scope to be diminished to a point where it’s not longer valuable. Again, the term is “Enterprise”. The value is in enterprise level planning and the reflection of changes in the entire enterprise. Identify very early to management how the products will be useful to the audience and how they will be distributed. How will feedback be gathered and integrated into the models?

Involve the users early in confirming and validating the models. Leading them through a few diagrams and products will quickly get them conversant in the modeling techniques.

With careful planning and clear expectations the enterprise architecture model will become a living reflection of the enterprise and a resource to all. The knowledge embodied in the EA should become a reflection of the organizational knowledge throughout the organization captured for reuse throughout time. A valuable asset indeed.

Don’t forget to leave your comments below.

Robert Jason Martin is an author and consultant living in St. Augustine, Florida. His work in business and systems consulting has taken him to most corners of the Earth working with a vast array of industries and governments, including many major world airlines. His first book was a text on the high-performance operating system that enables the world’s largest reservation systems to handle millions of transactions per day. He has designed multimedia and computer based training for a wide audience.


  • (1) Business Enterprise Architecture: The Formal Link between Strategy and Results, 2006 by CRC Press LLC by Whittle & Myrick, IBSN 0-8493-2788-1.
  • (2) Working Knowledge, 1998 Harvard Business School Press, by Davenport & Prusak, ISBN 1-57851-301-4.

The Tyranny of Best Practice and Its Effect on Requirements Elicitation

tyranny1How effective is today’s requirements elicitation? What do the statistics say? How long is your change request log? Did you ever wonder why there are so many changes during requirements definition? And why can so many project failures be traced back to the requirements?

I’d like to apologize because it’s partly my fault. I don’t mean just myself personally, but rather the generation of business analysts who crafted the foundation for today’s requirements elicitation best practices. That said, the blame shouldn’t be placed entirely on the shoulders of my generation. You see, part of the problem is our inability to learn, organizationally. Organizations have adopted a best practice approach to learning. And therein lies the problem. Let’s examine the serious drawbacks of this learning approach.

The best practice approach is based on evolution. It is slow, agonizingly slow. I don’t know what nature’s purpose is, but I can say with some certainty that in nature it is the strong and the prolific (great in numbers) that survive. Nature is not necessarily interested in keeping the “best”. So it is with best practices. How do best practices emerge?

It all starts with personal experience. We all have it, and we all develop personal practices around it. At some point, an organization may decide that it doesn’t want that many personal practices and it prefers a single organizational practice. So it sets about establishing one. A team is assembled, and based on their past experience, usually 5 – 10 years, they develop an organizational practice. But the one that ends up the winner, isn’t necessarily the best, but rather the one that gets consensus. Often this is a compromise close to the majority practice. Of course, we all know that the best is rarely in the majority. Practices are rarely subjected to verification. And so the strong survive, and we get an organizational practice. Now this practice needs to be propagated to the organization. The time-frame for this can easily be 5 – 10 years or even longer. So at the end of the day we have a practice based on experience that is 5 – 10 years old and which takes 5 – 10 years to spread through the organization. So we have a timeline of 10 – 20 years or more to develop an organizational practice.

Then along come consultants who notice these practices. In some they see an opportunity for business. And so, they get behind these practices. Of course, of the many practices out there, the ones with the greatest opportunity for them, are the ones that will get the most support. And so, these practices start to show up at conferences, in articles and in books. As more and more organizations are convinced to try them, we reach a critical point where hundred of organizations have tried the emerging “best practice”. Among the hundreds, we search for three to five organizations that are both well known, respected and successful. These become the poster boys for the marketing campaign to follow. Their success serves as the fuel for pushing the practice forward. The fact that failure rates for the practice exceed the 90% mark, are never revealed. All we need to show is that it can work, and that it has worked. Eventually, after 10 to 20 years or more, enough organizations are convinced, so we get a dramatic increase in adoption. Now it’s out of the hands of the proponents, the pushers, and into the hands of the adopters. The adopters now begin to talk to each other and stories of failures begin to increase. The true effectiveness begins to emerge. And within five to seven years, another best practice hits the dust.

And how long does all this take? It takes 10 to 50 years to discover that a best practice may not be that good. Can you afford to wait that long to try a practice developed by people based on experiences from decades ago? Six Sigma was branded in 1986 by Motorola based on principles that date back to 1920. It is just now beginning to achieve the level of adoption that immediately precedes abandonment. Lean was primarily developed following World War II by Toyota. The majority of Lean principles taught today were developed between 1945 and 1965. That’s practically ancient history. Again, it is just now beginning to achieve the level of adoption that immediately precedes abandonment. Now abandonment doesn’t mean it’ll completely disappear.

Hindsight is 20/20 – Until You Turn a Corner

Best practices are based on hindsight. The best practices for your job were developed primarily by people of my generation, based on our experience with Requirements Elicitation and Project Management. Unfortunately, our experiences were based on a completely different reality than today’s. We have turned a corner. Didn’t you get the email?

Today’s reality is considerably different. Our job was to automate well defined clerical jobs. Yours is to improve process performance. We dealt with departments with single points of authority. You deal with cross-functional groups with functional biases. We didn’t have change control. Change control has been introduced to fill an apparent oversight on our part. But actually, there was no oversight. We just didn’t have that many changes – our requirements were stable. Today the opposite is true. In fact you can view the length of your change control log as an indicator of risk. The longer your list, the more risky are your requirements.

I appreciate the compliment you are paying us, by basing your approach on ours. But you really shouldn’t have. We were working on cars, and you’re working on jets. Our world moved slowly so we could rely on personal practice to develop best practices. The timelines fit. But at today’s speeds, this approach doesn’t work. We were the more educated within the organization. We worked with dedicated but less educated employees, performing simpler jobs and were willing to be told what to do. You are working with a workforce that is more educated than yesterday’s most educated. Their work is more complex and more varied. And it changes more often and more quickly. As a business analyst, or process analyst, you have little hope of being able to understand to any level of detail all the work required in a complex process simply through interviewing, workshops and software.

But let’s review the conditions prevalent at the time:

  1. Computers were new and expensive.
  2. We didn’t have users yet. We had job experts.
  3. The job experts knew their jobs.
  4. The job experts didn’t know what computers could do. So they didn’t know what they wanted and we didn’t ask them what they wanted.
  5. Departments were full of people who did the same repetitive work and had been doing so for a long time.

So how did we gather requirements? We asked people what they did. We usually asked a few people knowing that everyone didn’t do things exactly the same way. Then based on what we understood from what they did, we designed a computer system to automate their job.

There are a few really important things to understand:

  1. We didn’t get many changes, because there was no opportunity for changes. If you ask someone what they do, and they have been doing it for years, they are not going to come back two weeks later and change their mind about what they did. We asked the job experts a question to which they had a firm, correct, and unchanging answer.
  2. The job experts didn’t have any notions of what computers could do, and so they didn’t interfere in the design process.
  3. The power of the computer to automate the simple jobs was so great, that it was difficult to fail.

How does that differ from today:

  1. You don’t ask subject matter experts what they do. You ask them what they need? The first is a question to which they have the answer. The second is a question to which they do NOT have the answer. The result is that the answer keeps changing. Hence, the long list of changes requests. Answering the question becomes a learning process.
  2. You aren’t in control of the design process. In fact, for most organizations, the design process has been abdicated to the SME committee. The assumption is that because you know how to assemble a car, you must also know how to design an assembly line. Clearly this is a false assumption. Designing and doing are two different disciplines. The people who design race cars are not the ones driving them, and vice versa.

We designed processes by looking backwards to what worked – best practices. We had the time. We had the stability. You have neither. You have little time and lots of change. You need to drop the best practice approach, because “best practices” are no longer a “best practice”. The world has moved on and so has your job. The paradigm has shifted. But the methods have not. That’s the bad news.

The good news is that the future business analyst job is more sophisticated, more impressive, will produce greater results for which you will be rewarded. You will be appreciated for your talent and your unique abilities. You will be seen as part of the business and not just a necessary appendage. But since your job has moved, so must you. Your new approach must be based on designing forward, rather than looking back. This requires that you move away from best practice and towards engineered design driven by performance. It means you have to move away from waiting for the market to accept a principle and towards testing it yourself to see if it works in your environment. It means that you can no longer speak to subject matter experts from across the table to elicit requirements they don’t have, but rather you must lead them in discovering what the higher level process needs in order to produce the desired value. Subject matter experts are not your customers in this exercise. They are part of a team. You are part of the same team, but you have a different role. So do they.

Designing to performance is a totally different paradigm from designing from experience. Designing to performance requires the introduction of science to the art of design. It requires concepts to be tested in real time, rather than distilled through generations of experience. Designing to performance takes the profession to a true profession based on scientific based knowledge, not committee-based knowledge. When medicine was based on best practice, leaches and blood-letting were accepted practices for centuries. Today’s medicine, based on science, has had more advances in one year than was possible in a century under the best practices approach. Best practices dissuade new approaches. Science kills ineffective approaches.

The choice is simple. You can continue to look behind you, after you have turned the corner. Or you can design to the future, while retaining not past practices, but rather enduring principles. You can continue to struggle along a winding mountain road on foot or switch to an automobile on a highway. For sure, it will take some time and effort to learn to drive, but isn’t it worth the ride?

How do you know when it’s time to shift to a new paradigm? When the conditions that lead to the current paradigm no longer exist, then we know we have turned a corner. The time to develop a new paradigm is just before we turn that corner. Unfortunately, we have turned that corner over two decades ago. Best practices are now holding us back. We must shift paradigms before someone switches us.

Don’t forget to leave your comments below

Angelo Baratta PMP, CMC, President of Performance Innovation is a practitioner and researcher. He has combined 25+ years of practical business experience with over 10,000 hours of research and development to produce ePPM Future Blue DesignTM – the art and science of discovering near perfect requirements. Used with Lean or Six Sigma it can help you to deliver from double to 10 times more value and turn Lean into a living and evolving methodology. Angelo’s experience comes from services, consulting, financial and manufacturing sectors allowing him to apply solutions across industry sectors. He is also a writer, presenter, instructor, consultant and coach. Angelo can be reached through www.PerformanceInnovation.com.

Beyond Requirements Analysis – Enterprise Analysis

“What do your Business Analysts do?”

“They develop and manage project requirements, of course. What else would they do?”

What else indeed!

The BA Body of Knowledge (BABOK®) defines what a professional BA should know and do. Much of it is focused on requirements work – but not all. One of the knowledge areas that takes the BA beyond requirements work is “Enterprise Analysis.”

Enterprise Analysis (EA) encompasses those activities that the job title “Business Analyst” actually points toward: analyzing business processes. The majority of these activities is outside of projects, and in fact, put the BA into the position of recommending and justifying projects.

Enterprise Analysis

Analyzing business processes is indeed a big part of what we do during Requirements Analysis. But that is not the only context where this analysis should be done, and in fact, it is not the most valuable time to do it. In the Enterprise Analysis knowledge area, the BABOK identifies several other contexts in which such analysis should be done.

Activity: Creating and Maintaining the Business Architecture

As the name of this activity implies, “Creating and Maintaining the Business Architecture” is an on-going activity that has as its focus the entire enterprise. The “Business Architecture” is a model of all the business processes that are used throughout the enterprise. It shows how they work and relate to each other.

The net result of this is an understanding that most organizations lack, of how all their moving parts mesh with each other. This broad understanding of the enterprise’s processes becomes the foundation for all of the other responsibilities of the BA. But its bigger value comes in providing every member of the organization with a clear understanding of how his or her department and individual job fits into the bigger picture

Recommending and Justifying Projects

The bulk of the activities described in the Enterprise Analysis knowledge area center around proposing and justifying projects. These are activities that occur in some form or other in any organization. But with the BA’s involvement, they can provide much more value and ensure the organization’s resources are spent on the most valuable projects.

Activity: Conducting Feasibility Studies

Projects are created to solve a problem or to take advantage of an opportunity. It is rare for there to be only one available solution to a problem or opportunity, so part of project initiation involves exploring the alternatives. The BA can provide a valuable service by calling upon his or her understanding of the Business Architecture to analyze the feasibility of a variety of options.

Activity: Determining Project Scope

Scope definition should not be the first step in requirements development; it should be done during the project proposal process. How can the decision-maker(s) approve or disapprove a project without a clear understanding of its boundaries?

Activity: Preparing the Business Case

The business case is the logical argument for embarking on a project. It consists of contrasting the status quo (current situation) with the various options for addressing the problem or opportunity at hand and recommending the most appropriate option. In most cases, these options are being contrasted in terms of money (e.g., “If we spend $x on this project, it will result in $y increased revenue per year”).

Activity: Conducting the Initial Risk Assessment

An important piece of information that the decision-makers need is an understanding of the risks involved in a project. Clearly, you cannot do a complete risk-planning workshop before the project has been initiated (that is part of the Project Planning process). But an initial survey of the project risks can provide the decision-makers with key information.

Activity: Preparing the Decision Package

The BA has no authority to approve or disapprove any project. The people who do have that authority rarely have the time that is necessary to do the requisite research. So, the BA’s role in the decision-making process is to do all of the necessary research, and compile it into a form the decision-makers can use.

Activity: Selecting and Prioritizing Projects

After a project has been approved, it should not be a foregone conclusion that it will begin immediately. Projects must be prioritized against each other so the organization’s resources can be deployed in the most appropriate way. Again, the BA is not the decision-maker, but provides the necessary analysis to the decision-makers.

Project Work beyond Requirements

The last three activities that the BABOK includes under the “Enterprise Analysis” knowledge area are project-related activities that go beyond Requirements Analysis. They continue the theme of Enterprise Analysis by maintaining a broad organizational view of the project.

Activity: Launching New Projects

Here, the BA works with the appropriate people in the organization to ensure that the necessary resources, including the right project manager, are committed to the project. The BA’s unique role in these activities is to focus on the bigger picture of why the project was approved and how it fits into the bigger organizational context. This ensures that the intent of the decision-makers is honored as the project is framed and kicked off.

Activity: Managing Projects for Value

In this activity, the BA works closely with the project manager to ensure the project is tracking toward providing the value that was promised in the business case (above). The BA helps the project manager keep the project’s value proposition on track. And if the assumptions on which the project was approved turn out to be false, the BA can help the decision-makers determine their best response.

Activity: Tracking Project Benefits

In this last activity, the BA closes the loop on the business case (above). The business case proposed making certain investments in order to accrue certain benefits. After the project is over, the actual investments are known, and the actual benefits can be measured. At some appropriate time after deployment, the BA should report back to the decision-makers about how the results of the project compare with the business case. This discussion process will help the organization make better decisions in the future.

Expanding Your Value as a BA

Requirements Analysis is an important way for the BA to provide value to his or her organization. By adding Enterprise Analysis, the BA can dramatically increase his or her value by ensuring that every project fits well into the bigger picture and provides the best possible result to the organization.

Don’t forget to leave your comments below

Alan S. Koch, PMP is a speaker and writer on effective Project Management Methods. He is a certified Project Management Professional and President of ASK Process, Inc, a training and consulting company that helps companies to improve the return on their software investment by focusing on the quality of both their software products and the processes they use to develop them.

Mr. Koch’s 29 years in software development include:14 years designing, developing and maintaining software; five plus years in Quality Assurance (including establishing and managing a QA department); eight years in Software Process Improvement and 10 years in management

Mr. Koch was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years where he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal Software Process (PSP) and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).

For more information about Mr. Koch: http://www.ASKProcess.com/experience.html.

This article was originally published in Global Knowledge’s Business Brief newsletter. (www.globalknowledge.com)

Copyright © Global Knowledge Training LLC. All rights reserved

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.


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.