Tag: Strategic & Business Management

From the Sponsor’s Desk: Nine Criteria for Project Prioritization

Written by Drew Davison on January 25, 2016. Posted in Articles. 10 Comments on From the Sponsor’s Desk: Nine Criteria for Project Prioritization

In most organizations, the demand for project work far exceeds the funding and resources available. Approaches to resolving this challenge vary from pitched power struggles, rigorous portfolio management practices and demand management arrangements to siloing strategies and executive dictates.

In this post, we’ll look at a company that came to grips with the excess demand challenge using a simple, nine point ranking process. Project proponents used the tool to quantify the potential enterprise value of each proposal. All submissions were then ranked to select the top value proposals. The cut-off was established based on the estimated level of affordability for the upcoming year, nicely matching demand with capacity. Simple, consistent, fast and good for the organization.

Thanks to I.B. for his contributions in this case.

The Situation

This manufacturing organization faced an ongoing challenge to balance demand for project resources with organizational value, affordability and the profit expectations of its shareowners. Past attempts to deal with the issue had resulted in the use of a number of new practices: in-depth business cases, funding allocations by division based on a high-level assessment of divisional contribution to strategic objectives, quarterly funding allocations, and a formal gating process.

The CFO was still not satisfied with the prioritization and funding approaches. He believed that many short and long-term profit opportunities were being left on the table. He discussed his reservations with his CEO and other senior executives but found support to address the issue lukewarm at best. So he set out to see what other organizations were doing to address the challenge as a prelude to revising their own internal practices. He assigned one of his Finance managers to take on the challenge.

The Goal

To investigate best practices being used by market leaders in their industry and in other industries, assess how those practices were contributing to organizational success, and make recommendations to improve their own internal operations. The assigned manager was challenged to have a formal, justified proposal in place within six months to coincide with the start of the corporate budgeting cycle. Any funding required would come from the manager’s operating budget with assistance from the CFO’s budget as needed.

The Project

The Finance Manager enlisted a couple of his senior staff and started a literature search for project prioritization and funding practices to get the ball rolling. He also engaged with the Systems Development Manager about key project success factors and project management best practices. The four of them were soon overwhelmed with information. They decided to constrain the scope of the undertaking by developing an assessment matrix that addressed four components:

No more than ten selection criteria
A rating scale for each criteria that would produce a confirmable and quantitative result
Weighting for each criteria that could be adjusted to reflect current corporate priorities
A total score that could be used to rank projects

The Finance Manager also suggested that they stage their efforts to test concepts rapidly, garner feedback and iterate until they had a solid proposal and test the models on their current project inventory and backlog. His teammates agreed. The CFO agreed.

The team of four developed three iterations over fourteen weeks. Each iteration was tested on the current project inventory and the results reviewed with the CFO. Based on qualitative and quantitative assessments, the model was revised, and a new iteration was processed for subsequent review. In three months, the Finance Manager and CFO were ready to present their findings and recommendations to the company’s executives for approval.

The Results

After some stubborn resistance and localized grumbling, the proposed project prioritization and ranking process was approved unanimously by the company’s executives for use in the upcoming budget cycle. The prioritization mechanism included the following components: a stakeholder model, prioritization matrix and a process guide.

Stakeholder Model

Four roles were defined in the Stakeholder Model:

Process Owner – the CFO was identified as the owner of the process and the final arbiter on any issues related to the operation of the prioritization and ranking practice.
Reviewing Partners – the members of the Executive Committee were identified as Reviewing Partners, responsible for vetting every submission to ensure completeness and consistency across the portfolio
Submission Owners – the Sponsors of the submitted proposals were designated as the Submission Owners. They were responsible for the accuracy and integrity of the submissions. They were also responsible for socializing the proposal and ensuring all stakeholders were on side.
Collaborators – the change Targets were identified as Collaborators. They were responsible for signing off on the accuracy and integrity of the submissions before they were presented for consideration

Prioritization Matrix

Nine assessment criteria were selected as the primary indicators of worth and risk with an assessment scale for each. As well, they defined the Value and Weight ratings for the criteria. The team saw the Value rating as an important indicator of project success that would stay constant from year to year. The Weight rating, on the other hand, could be varied year by year to reflect the needs of the corporation, from shorter term, lower risk projects to high strategic alignment.

The assessment criteria included:

1. Sponsors – Sponsorship was seen as a key success factor. However, the more sponsors there were on a project, the greater the risk. The scale was Number of Sponsors, the Value was set at 20%, the Weight at 20% and the total calculated as Value/# Sponsors*Weight.

2. Targets – Targets are the managers/decision makers of organizations affected by a planned change. As with Sponsors, the more Targets involved, the greater the risk. The scale was Number of Targets, the Value was set at 20%, the Weight at 10% and the total calculated as Value/# Targets*Weight.

3. Associated Projects – Associated Projects was included to identify inter-dependencies that needed to be considered during project selection. Of course, the more Associated Projects, the greater the risk. The scale was Number of Associated Projects, the Value was set at 10%, the Weight at 10% and the total calculated as Value/# Projects*Weight.

4. Supported Strategies – Supported Strategies was included to reflect strategic alignment. As well, it allowed for an analysis of potential inter-dependencies and identification of gaps in strategic support. The scale was Number of Supported Strategies, the Value was set at 15%, the Weight at 10% and the total calculated as Value*# Strategies*Weight

5. Strategic Fit – Strategic Fit focused on the significance of a project’s support for stated corporate and line of business strategic goals.

The scale was defined as:

Critical to the success of the line of business and corporate goals	5
Necessary to deliver the line of business and corporate goals	4
Supports the line of business and corporate goals	3
Tactical with strategic component	2
Tactical solutions only	1
Has no direct or indirect relationship to corporate vision	0

The Value was set at 10%, the Weight at 10% and the total calculated as Value*Strategic Fit*Weight.

6. Economic Impact – Economic Impact considered the value expected to be delivered to the organization in terms of annual benefit and payback. The scale was defined as:

under 1 year	5
1-2 years	4
2-3 years	3
3-4 years	2
4-5 years	1
5+ years	0

The Value was set at 10%, the Weight at 15% and the total calculated as Value*Economic Impact*Weight.

7. Competitive Advantage – Competitive Advantage focused on the value derived from implementation of a project supporting a new business strategy, product or service. The scale was defined as:

Substantially improves competitive position (12 month window)	3
Moderately improves the competitive position (6 month window)	1
Brings the level of service/products in line with competition	0

The Value was set at 5%, the Weight at 10% and the total calculated as Value* Competitive Advantage *Weight.

8. Competitive Risk – Competitive Risk assessed the degree to which failure to do the project will cause competitive damage. The scale was defined as:

Postponement will result in irrevocable damage	5
Postponement will result in further competitive disadvantage	4
Postponement may result in further competitive disadvantage	3
Can be postponed for up to 12 months without affecting competitive position	1
Can be postponed indefinitely without affecting competitive position	0

The Value was set at 5%, the Weight at 10% and the total calculated as Value* Competitive Risk *Weight.

9. Project Risk – Project Risk focused on the degree to which the organization is capable of carrying out the changes required by the project. This is a negative factor. Higher measurements represent greater risk. The scale was defined as:

Magnitude of change

Major change for targets	5
Moderate change for targets	3
Minor change for targets	1

Primary target of change

Customer	10
Field or remote locations	5
Internal	1

Management commitment

No active sponsorship	10
Actively managed at mid-management levels	3
Actively sponsored at highest level	1

Project management/skill sets

Inexperienced	10
Somewhat experienced	3
Experienced and capable	1

Cross-organizational implications

Affects all services or lines of business	10
Affects multiple services or lines of business	3
Confined to limited services or lines of business	1

Magnitude of business & technology changes

Major change to existing environment	5
Completely new business or technology	3
Minor changes to existing environment	1

Clarity of business need

Ill-defined	10
Generally understood	3
Clearly defined	1

Knowledge of target solution

Brand new product or service	5
Somewhat new/limited applications	3
Very well-known/industry wide	1

Total

For total scores of 8-26, the risk rating is Low
For total scores of 27-46, the risk rating is Medium
For total scores of 47-65, the risk rating is High

The Value was set at 5%, the Weight at 5% and the total calculated as -Value* Project Risk *Weight, a negative number that reduced the overall project rating. The higher the risk rating, the larger the reduction.

In addition, two additional pieces of information were required: Annual Benefit and Payback Period. At this early stage, it didn’t make much sense to try and develop cost estimates. Instead, the submission proponents were asked to calculate a projected annual benefit and the payback period required based on the nature of the change. For example, operational changes would be expected to provide a quick return (usually less than a year). Tactical initiatives should have a payback within one to three years, and strategic undertakings could have a payback period of three years or greater. That information was used to arrive at target investment amount (annual benefit x payback period). The target investment was used as a proxy for estimated cost on the proviso that the solution would be managed within that number.

The Prioritization Matrix was presented in a worksheet form that submitters were required to complete, socialize, present and defend in seeking funding for their initiative.

Completing the worksheet was an informative process for the participants. They were often forced to go back and reconsider aspects of their proposal to increase the value and reduce the risk in an effort to improve the total score. Often, what started out as a multiple sponsor initiative ended up with one, more committed sponsor. Proposals that had a significant risk were often reconfigured to reduce the risk and increase the chance of funding. On occasion, proposals were dropped from consideration when the sponsor and collaborators realized what looked like a great idea didn’t pan out with further due diligence.

Process Guide

The Process Guide was developed to provide a roadmap for those involved in the project prioritization exercise.

The Process Guide included eight steps, from conceptualization to the final decision regarding the projects to be funded. The sponsoring executive was required to ensure proposed projects were socialized with managers affected by the change and that affected decision makers were in agreement.

Each initiative was presented by the sponsoring executive in an executive scrum. The presenting executive was challenged by his or her peers to justify each position, especially the specific strategies supported and the ratings for strategic fit, economic impact, competitive advantage, competitive risk, project risk, forecast annual benefit and the target payback period.

There were heated debates about most of the submissions and the values assigned. In many cases, the debate was taken offline where further discussions and investigations resulted in modified and resubmitted proposals. The process had two significant benefits: the proposals, when finally approved for funding, where solid, well research, fully supported ventures and, all senior executives were fully informed about the initiatives going forward. The CFO, in his role as process owner, was responsible for making a final call on a proposal if an agreement couldn’t be achieved in the scrum sessions.

The CFO’s staff accumulated a list of approved proposals in a ranking table and ordered it by the prioritization total, below.

Individual project proposal totals and rankings could be tweaked by the CFO’s staff to reflect project inter-dependencies, mandatory initiatives like government legislation, critical operational fixes, and other planning opportunities. Finally, the CFO’s staff would determine the appropriate level of funding to commit for the upcoming period and draw a line across the ranking chart. Projects lying above that total would get funded. Projects below the line would not.

After the first use of the prioritization practice and completion of the budget cycle, the CFO’s staff surveyed those involved to see how the practice met its goals. The almost unanimous feedback: simple, consistent, fast and great for the organization.

How Great Leaders Delivered

From the millions of hits returned on an internet search for “project prioritization”, this is obviously a challenge for many organizations. There are also undoubtedly a plethora of solutions. The CFO and his Finance Manager and team did a number of things right to solve the prioritization challenge for the organization and deliver a solution that was right for them.

Collaborate – The CFO sounded out his colleagues at the outset and received a lukewarm reception. But through that initial contact, the other executives knew something was probably afoot so they weren’t surprised when the proposal was presented to them. Also, collaboration was at the core of the prioritization practice and contributed significantly to its success.
Reuse – The Finance Manager and his teammates started with a broad search for applicable practices. They certainly weren’t disappointed. Reusing what others had developed and discovered before, they were able to develop a practical, powerful solution quickly and cost-effectively.
Test – The team’s decision to iterate, review and test the output on their existing project inventory allowed for a rapid discovery cycle while minimizing the investment of time and accumulation of vested interests. Was their solution perfect? Certainly not. What they did get though was good enough to meet the challenge.
KISS – Keep It Simple Silly. They did keep it simple. Nine factors. A simple scale for each. A Value rating. A Weight rating. An annual benefit. A target payback period. Add them all up to get a total. Review with others. Decide. Oh, and they used Excel.
Measure – The CFO’s team worked with the sponsors and collaborators to complete the worksheets and go through the review and decision processes. They adjusted the materials based on the feedback received. They communicated widely, about usage, number of proposals under development, received, reviewed and approved. They interviewed the executives midway through the budgeting process and made appropriate revisions. They surveyed the users after the budget cycle and communicated the results. They knew how the process was performing throughout the budgeting cycle.

In my mind, this is a great example of a solution fitting the need. It wasn’t the perfect solution. But it was more than good enough. So, if you find yourself in a similar situation, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors. Finally, thanks to everyone who has willingly shared your experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

Collaborative Leadership: Managing in the Matrix

Written by George Pitagorsky on January 11, 2016. Posted in Articles. 5 Comments on Collaborative Leadership: Managing in the Matrix

“A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.” Lao Tzu

The most effective leader doesn’t dictate or mandate, they set direction and eliminate roadblocks. The great leader collaborates with his subordinates, peers, and superiors. He asks more questions and gives fewer orders, deadlines, and directives. At the same time, the great leader must know the character of the people. Not just subordinates but also peers and superiors. Leaders lead across hierarchies and must change their style to suit the situation and the needs of the people they are dealing with.

Leadership starts with a vision. A collaborative approach implies that the vision begins as a draft or seed. It is presented and then evolves through dialogue so that it is owned by all stakeholders. While collaboration takes much more time and effort than the alternative, it pays off. A dictated vision is less likely to be attained than one that has resulted from the contributions and approval of the people who will actualize it and live with the results.

We must transform theoretical into practical for it to be of any use. The theory of a collaborative leadership approach has been expressed many times in many contexts. How does it translate into practical action that a Project Manager can apply in the real world?

We will use obtaining estimates and setting targets as an example of the application of a collaborative approach.

Working in The Matrix

Most Project Managers do not have direct authority over the people working on their projects. When working with “matrixed” resources, collaboration is a must. Anyone who has ever tried to force a deadline on a functional manager or a member of a functional group or operational user organization knows this experientially. Unfortunately, that doesn’t stop them from doing it again. Why? Because of fear and the belief that there is no choice.

The big boss says, “I want this by next Tuesday.” The PM knows that to do it by then Task X must be done by this Thursday. Therefore, the PM thinks there is no choice but to mandate the date to the people responsible for Task X. He’s got to meet the big boss’ deadline.

He goes to the functional manager in charge of the group responsible for Task X and says, “You have to complete your task by Thursday in order for me to meet my deadline.”

The functional manager could comply and deliver. Everyone is happy.

What’s the likelihood of that in your situation?

The functional manager who doesn’t know how to or doesn’t like to say no could say he will comply and not deliver. A different functional manager might laugh and walk away.
Do these responses ever happen? Neither of them is particularly healthy.

An alternative scenario is that the functional manager, who is clever enough and kind enough to take your statement as a question (“Can you deliver?”), assesses the task and says that there is no way it can be done in that time frame, because the effort and duration required are too great and/or there is a backlog of work and therefore no resources to put on the task. We could do Task X by a week from next Tuesday.

If lack of resources is the reason for not being able to hit the deadline, a priority change or additional resources could resolve the problem. That would require a decision from on-high.

There is a choice

The Project Manager who thinks there is no choice but to comply with the big boss’ deadline is in trouble; caught between a rock (the functional manager who says ‘no’) and a hard place (the boss’ deadline). The PM who recognizes that there is a choice has some hope.

The choice is to go back to the boss with a logical and fact based argument and say “Can’t do it by then. It can be done by a later date unless you and/or your peers change priorities. If you do change priorities, then you will have to bear the cost of slowing down or interrupting other work. Still want it?”

This is taking a collaborative approach in managing your peers and superiors. As a leader, you have enabled your boss (or client) to make a decision and set a rational deadline. You have protected your team and yourself from a forced march to failure. You have protected your boss from having unmet expectations and making promises to his boss that cannot be fulfilled.

Of course, doing this means that you must overcome your fear of pushing back and your perception that what the boss says is an unconditional command. Take the command as a question, just like the clever and kind functional manager did.

Also, recognize that your boss may be completely irrational and not care about the facts and logic. He may just want what he wants and think that wanting will make it happen. It might, but at what cost in quality, morale, and trade-offs outside of the boss’ limited purview. This kind of boss, you want to fire.

Managing Direct Reports

Now let’s change the scenario, instead of relying on people from other groups, who don’t report to you, the entire deliverable required by the boss can be delivered by your direct reports; people who you can order around and mandate the delivery date.

The collaborative leader will not mandate the deadline. He will say what needs to be done and ask “When can you deliver?” If the answer is not by next Thursday, then he will ask why and how it could be done sooner. In effect, he is managing his direct reports, his subordinates as if they were peers or superiors.

The result would then be the same as with the functional manager, a choice for the boss.

The PM who pushes down demands rather than pushing back with a logical and fact based argument is not a leader; not even a good manager. While he might get his staff to accept irrational deadlines, he really can’t expect them to meet them while meeting the other demands made on them.

There is damage to morale and a loss of respect for the managers who push down irrational demands. Subordinates view them as being fearful, uncaring and weak. They become angry at being forced into a no-win position. Often the best talent leaves.

Collaborative Leadership

In general, telling people what to do and how to do it will result in suboptimal outcomes. The most valuable staff will lose confidence in their boss, suffer from low morale and may leave for greener pastures. People will cut corners and deliver shoddy results. Deadlines will be missed. Stress levels will increase. People will learn to be told what to do rather than to take initiative.

By asking your staff for their input and treating them as peers, you will create a healthier work environment and bring out the best in people. By considering even your boss’ boss as a peer, you will be better able to help her to achieve her objectives.

5 Project Management Mistakes that Can Get You Sued

Written by Brad Egeland on December 29, 2015. Posted in Articles. 5 Comments on 5 Project Management Mistakes that Can Get You Sued

I’m an independent consultant AND a Project Manager. My online reputation is everything, and the last thing I want would be to have a lawsuit directed at me suddenly.

If you’re consulting or performing PM services through a third party that is paying you, then generally you’re covered by that organization. And if not, then your own liability insurance will cover you. Still the negative connotation of being a party in a lawsuit is enough to cause harm to a consulting or project management practice. So – hint – you want to avoid a lawsuit whenever possible.

I’m sure there are many ways to quickly get yourself into the middle of an ugly lawsuit as a Project Manager or consultant, all of which we want to avoid. What I’m going to cover here are the top 5 that come to mind for me. Again, this is far from a comprehensive list, so please be ready to share your own thoughts and experiences and let’s discuss.

Providing an unusable end solution. This one goes without saying. Obviously, if you blow through the client’s project budget and turn over an unusable solution to their end users, you might find yourself the subject of a lawsuit. Always show yourself as willing to right any wrong and stay with a project until you get it right. You will greatly reduce your chances of facing a lawsuit if the project fails at first but stick with it to make it right or, at least, show good effort and intent. A good show of faith in the face of project adversity will help the client to see that you are on their side and are willing to do whatever it takes to fix the end solution as much as possible. I’m not saying you won’t have to give away some free work. You likely will but just about anything is better than an expensive and disruptive lawsuit.

Misrepresenting your credentials and experience. You shouldn’t lie on your resume, and you shouldn’t lie on your website. Never give yourself credit for credentials you don’t have. I’m not sure how easy it is for someone to check your credentials or how many even would, but you just don’t do that. And, if that deceit is coupled with any failures on your part during the course of the project, a lawsuit may happen. The integrity of the Project Manager or consultant should never be in question. The minute it is, the word can get around fast, and you may find yourself losing all of your clients at once, and fast.

Leaking proprietary client information to a competitor. Most project clients will want you to sign a non-disclosure agreement (NDA). There also may be a formal contract involved. Either way, logic should tell you that you don’t leak proprietary client information to anyone, let alone a competitor of your valued client. I have had several clients writing into our agreement a list of direct competitors that I agree not to work with while I’m engaged with this client. Our project clients are important – honor all such agreements and always be above and beyond reproach. I don’t even like to give out client names when prospective customers ask for references. I avoid this at all costs. It’s been a good practice for me.

Related Article: Strategies to Keep Your Project on Track

Failing to cover your bases with signoffs/approvals. I’m not saying you always need formal signoffs on all deliverables. But why not? You never know when you might run up against a client who seems a bit overly litigious, and if you don’t have the documentation to prove that you met dates, milestones, and deliverables along the way, then you could find yourself being sued without the documentation to defend yourself. Come up with a formal, generic signoff sheet or email for each deliverable and ask your client to sign it or respond to the email with their approval. That documentation may be golden one day. Always be careful.

Failure to document requirements well. As Project Managers, we all know that it’s a bad idea to embark on a project without good, detailed project requirements in place. It’s what you use to develop your customer’s final solution. Unfortunately, bad requirements happen all the time, and they can lead to projects going over budget, over time, and – if not corrected at all – the final result may be an end solution that isn’t usable. So really, this one can overlap a bit with the first topic above. But requirements are the lifeblood of the project and as the delivery organization it is your job to make sure that the requirements are well documented and signoff/approved by the project client. If you have poor requirements to develop the solution from then, don’t start the project work until you have good requirements. If you start, then the finger will be pointed at you, and a lawsuit may come about.

Summary / call for input

Lawsuits are ugly. Customers can sometimes be overly litigious. And sometimes you don’t know that until the project is well underway. A lawsuit may have a basis, or it may be unfounded…but either way, it can be damaging to you. Be honest, by above reproach, follow through, and don’t forget to document everything.

Thankfully, I’ve never even been close to being involved in one. No threats, no actions. The key is to be open and honest with your project clients at all times and always give them your best. Failure happens, but if the project client knows you’ve been upfront with info, have given the project 100% and are willing to do what you can to fix issues along the way, then you will greatly reduce any chance of legal action should failure be the final outcome. Stick with the client and make their satisfaction your ultimate goal. It will always work to your benefit over time.

How about our readers? What are your thoughts on this? Have you or your organization ever faced a lawsuit as a result of a failed project? What happened? What did you do to work it out with the client? Please share and discuss.

Key Performance Indicators; How to Use Them for Project Success

Written by Curt Finch on May 16, 2012. Posted in Articles. 2 Comments on Key Performance Indicators; How to Use Them for Project Success

Companies that sell services to other businesses-project management, data management, software development or IT consultancies, for example-often track time in order to automate invoicing, but they may be overlooking the other benefits these systems can provide. Real-time access to relevant Key Performance Indicators (KPIs) such as ‘percent billable’ and ‘completed vs. estimated’ can give early warnings of project problems and lead your company to faster growth and more profitability. I would first like to explain what KPIs are, and then show you how to use some simple ones to improve your business or rate of project success that can be calculated from any time and data labor source.

A key performance indicator is ‘key,’ which means that your KPI has to be one of a very few things that you are measuring which you believe will make a huge difference to your business long-term. In other words, a KPI measures progress toward a strategic goal. If you have 100 KPIs, then you’re not going to be able to use any of them to drive organizational behavior because your company doesn’t have 100 strategic goals. Ten KPIs can be effective, five KPIs are better, and one KPI is ideal.

Related Article: Measuring Project Success Using Business KPIs

A Quantifiable Indicator. A KPI must be measurable. “Make customers more successful” is not an effective KPI without some way to measure the success of your customers. “Be the most convenient drugstore” won’t work either if there is no way to measure convenience. It is also important for KPI definitions to remain stable from year to year. For a KPI of “increase utilization rates,” you need to address considerations like whether to measure by hours or by dollars.

Performance Measurement. KPIs are used to measure the performance of a project or organization, frequently through activities such as performance improvement derived from training, labor utilization rates, or customer satisfaction. KPIs are often tied to strategy through techniques such as the Balanced Scorecard, but they don’t have to be as complicated as that to be useful and effective. As with most things, simplicity increases efficacy.

KPIs can differ depending on strategy. They help an organization to measure progress towards their organizational goals, such as increased penetration of existing customers or markets, on-time delivery or reduced scope creep.

A KPI is part of a ‘SMART’ goal-one that is Specific, Measurable, Achievable, Relevant, and Time-based-which is made up of a direction, KPI, target and time frame. An example of this would be to “increase average revenue per sale to $10,000 by January.” In this case, ‘average revenue per sale’ is the KPI. The aforementioned goal wouldn’t be SMART if it wasn’t achievable, if the word ‘January’ was left out, or if was not relevant, e.g. if this was a portion of the organization that had nothing to do with sales or marketing, like HR.

Simple, Useful KPIs

Billability (often termed ‘utilization rate’) is the percentage of time in a given period during which employees are working in a revenue-producing capacity. You must configure your timesheet system to track whether or not work on a project is considered billable to the customer. Once you have this information, utilization for any period, group or person is found by the formula B divided by T, where:

B = billable hours for the employee/group in the period

T = all hours worked for the employee/group in the period

Most organizations try to keep their utilization rate above 70% or so. The higher, the better, until you’ve reached a point where administrative tasks that are necessary to the business or specific project (like tracking time) are not getting accomplished. Then you know you’ve pushed it too far.

Adherence to Estimate. Customers do not like it when you underbid, but you won’t win the business if you overbid. Many consultancies do a poor job in this area. The KPI you want to minimize here is defined by the formula [(E-A)/E] where:

E = estimated hours to complete project

A = actual hours used to complete project

Just tracking this KPI is a good start, and you can get the data to calculate it from any timesheet system, even paper ones. Automated systems, however, often have reports to calculate it for you. Improving this number can be difficult for some companies until they understand a simple truth-that similar projects often have a strikingly similar ratio of early phase cost to overall project cost.

The early phases of a project are usually referred to as the ‘requirements,’ ‘design,’ or ‘specification’ phases, depending on what your consultancy is doing. If you find that after carefully tracking time on a batch of similar projects, the first two phases usually take about 10% of the total project time, you can use that data to predict the length of future projects.

The following diagram shows how tracking the time it takes to complete a project helps in planning future projects. By tracking time and subsequently learning that the first two phases of Projects 1 and 2 took 10% of all project time to complete, the projected length of Project 3 becomes easy to determine. If the first two phases of Project 3 take 1.8 months to complete, you can estimate that the entire project will be completed in 18 months. This project estimation technique has proven itself to be extremely accurate for similar projects in a variety of companies.

Percentage of Projects Profitable is a KPI that can really affect your business in a positive way. As an analogy, consider a Journyx customer, British Petroleum (BP), and their experiences in drilling for oil. They created a strategic vision for their company which they termed ‘no dry holes’. Drilling for oil and not finding it is expensive. Rather than trying to make up for all the dry holes by finding an occasional gusher, BP decided to try to never have a dry hole in the first place. Changing the attitude that dry holes were an inevitable cost of doing business fundamentally changed their culture in very positive ways.

Project management and other consultancies also have dry holes: projects which lose money for the company. Due to an inadequate understanding of costs, many of these go unnoticed. If you set a strategic goal for your company of ‘no unprofitable projects,’ it will change the nature of discussions in your business.

For example, it empowers frontline employees to legitimately push back when a project is being taken on for political reasons. Conversely, having the attitude that the winners will make up for the losers doesn’t do this. Getting direct per-project cost data from a timesheet system is easy. Correctly applying indirect data (such as sales or accounting time) to the direct costs is a bit more complicated. Connecting all of this to revenue data gives you per-project profitability. Once you have that data, you can work on your KPI of ‘percentage of profitable projects’ and try to maximize it. The formula for this KPI for a given time period (usually a quarter or a year) is:

# of profitable projects / # of projects

You should seek to maximize this number. Even if you are willing to lose money on a few strategic projects in order to enter a certain market, you should determine how many you’re willing to do that on, and keep your losses around that area reasonable.

Conclusion

These are three examples of KPIs that you may find useful, with information on how to calculate them. None of these requires an automated system (although that dramatically lowers the effort of data collection). Other KPIs that could be useful are ‘calendar time to complete a job’ (because overhead costs increase substantially due to all the status communication problems when there are delays), ‘percentage of customers satisfied’ and ‘time to complete initial free estimate.’ Any of these may be right for your business once you’ve chosen a strategy, but a strategy without metrics won’t get you very far. KPIs are the answer.

Curt Finch is the CEO of Journyx (http://pr.journyx.com), a provider of Web-based software located in Austin, Texas, that tracks time and project accounting solutions to guide customers to per-person, per-project profitability. 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. In 1997, Curt created the world’s first Internet-based timesheet application – the foundation for the current Journyx product offering. Curt is an avid speaker and author, and recently published All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource.