Infinite Shades of Grey

Okay if you are an Architect or PM  reader of my blog, you are about to receive a free gift, others will likely be bored silly by this one.  This gift is the result of hundreds of hours of research, real life practical experience and has successfully estimated many projects that completed on-time and on-budget. No royalties requested or expected.

Now some will tell you that Project estimation is a science. It is not. It is an art form.  It is an art because the best, most accurate estimate in the world is valueless unless you can convince your client that you are right. This methodology has the ability to make that proof.

There are 3 basic dimensions of the estimation problem.

– how much stuff do you have to do that you know about?

– how much stuff do you have to do that you don’t know about yet?

– how good are you at doing it?

Which really has two sub-categories

• How productive are you?
• How many mistakes will you make that you will have to fix?

So let’s put a metrics framework around these dimensions.

– Stuff you know about – Let’s measure it in Function Points (IFPUG standard) http://ifpug.org/

– Stuff you don’t know about – Let’s call these contingency Function Points

– How good at it are you – We’ll measure this in Hours per Function point.

– How many mistakes will you make that have to be fixed? – We will also measure these as contingency function points.

In it’s most basic (and useless) form. The estimate starts as

Now I will assume you can read the IFPUG guide and learn how to count function points. It is a well-established, architecturally independent mechanism for sizing any application existing or future. To grossly oversimplify it, it counts stuff the system does. The more stuff it does, the more functions points. The method then asks questions about non-functional requirements such as performance, security, networks etc and then bumps the count accordingly based on complexity. You can hate it or love it, but the method works, for sizing the application in question.

This will provide you with your Core Function Point count.

The next important selection is “how good are you?”

Here is what you need to know. It is both development environment and skill specific. Here are my magic numbers.

1. 3GL environment with a solid development toolset and highly competent resources – 16 hours per function point
2. OO language with solid development toolset and highly competent resources – 14 hours per function point
3. OO language with great toolset, strong re-usable library and team that has worked together before well – 12 hours per function point
4. OO the above, but a very small team (4-6 developers) with agile methods and customer who can make decisions immediately – 8 hours per function point

*** Note: Hours per function This is NOT just development time ***

This is the complete time required to deliver the functionality associated with that function point. It includes:

You may wish to change the percentages to reflect your own experience, but the numbers here are the industry standard for projects > 1000 function points and the averages of more than 3,000 reporting projects. This is the list you provide when your PM tells you they need 20% of the billable hours to do their job properly. If they do… time to get a new PM.

So lets assume team type 3 and a 2,000 function point system.  The base calculation is Total Hours = 2,000 FP x 12 HRs/FP = 24,000 Hours = 12 Person Years Effort

This provides you with overall hours (less contingency). Let’s use Ian’s magic estimator tool now to break this down for an actual project into a Unified methodology.

The spreadsheet provides a methodology specific breakdown of the hours based on best practice metrics.

You adjust the team size for associated schedules (with some caution on reducing the timeline below reasonable delivery windows)

The next step is to provide an average load by resource (initially equally balanced across the project to drive the cost numbers on a fixed run rate) and then load the resources to the average by phase (keeping costs in-line with the standard).

Now we add the rates for each resource class and you have a project cost without contingency,

So we have now modeled a 15 month project, with average FTE’s of 12 with a cost of $2.4 Million dollars without contingency.

Now we need to talk about contingency and rework. These are calculated on your basic plan.

Rework is likely the simpler to assess. Rework changes dependent on:

– how much you know about the business domain

– how expert your customer is about the business domain

ie. is it a new area or are they taking a very known process and automating it differently.

– how many true design or coding errors/bugs you will introduce into the system.

My rule of thumb is as follows:

2% of total FP’s if my team is unfamiliar with the domain and add it across the project

5% of total FP’s if my customer is doing something “new” to them and add it to the Inception and Elaboration phases.

0.6% of total FP’s for each if  any of the tools, libraries or resource experience level are substandard for the team level chosen and add it to stabilization phase.

use the average cost per function point $2.4 Million divided by 2000 = $1200

Example: We understand the domain  (let’s say Ecommerce) the customer does not and Team Level 3 meets all the criteria. I will then add 5% of the total FP as contingency.

2000 * 5% =  100 @ $1200 each. I add $120,000 to the inception and elaboration phase as contingency buffer only.

Applying this process has some art and some science. By working through it with your customer they will see the timelines based on industry methods and your confidence in delivery based on productivity.

It is also NEVER a discussion about rate and I always use this example with customers

2000 functions points @ 16 HR/FP = 32000 hour project @ $100 /HR  =  $3.2 Million

2000 function points @ 8 HR/FP = 16000 hour project @ $150 / HR =  $2.4 Million

You make the argument about productivity not the hourly rate. Smart customers pay for performance and high performance consultants are great value even at higher rates. Smart customers can also use this same tool to sanity check the quote they received for doing a build.

If you would like my estimation framework spreadsheet to try the calculations, feel free to email me.

It seems like such a simple question but often it is not such a simple answer. What I do know is the wrong answer to this question. The simple and always wrong answer is ABC company, the place I am working.  Learning how to discern who your client is may be the single most important consulting skill you will learn. It’s harder than you think.

Example: You work for a large systems integrator. They have a customer they wish to sell a solution to. Say an ERP solution that they have developed or have a partnership with a specific vendor. They send you into their customer at no charge and ask you to do a requirements and architecture analysis to determine the “fit” of the proposed solution. Let’s call the systems integrator SI and the customer ABC co.

Is ABC co your client?

Is SI your client?

Let’s ask two important questions.

1) Who commissioned the work?

2) Who will ultimately  decides whether you succeeded or failed at the engagement and authorize the payment of your fee?

In this example, it is clear that “SI” commissioned the work with a specific task of determining the delta between their product and what the company needs.  “SI” will also decide whether the analysis and architecture work done meets their requirements. So who is your client?

Well, the technical answer is “SI”. So now what happens when you are engaged by “SI” and you determine that the “SI” product is an incorrect fit for this customer. You are fully aware of better, lower cost solutions not provided by “SI” but would be very beneficial to ABC co.  Now what?

Let’s take another example. The CIO of ABC Co. decides that he or she needs an enterprise-wide architecture review completed and hires your firm to complete the activities. You are assigned the task and are told to work with the Director of Architecture for ABC Co.  The director is very specific that they would like you to look only at portal and integration architectures and will provide the required technologists for your to talk to. Who is your client? The Director of Architecture, the CIO or ABC Co.?

Apply the test. The work was commissioned by the CIO and ultimately the CIO will decide whether what you produce on the engagement met his or her expectations and authorize the payment of your fee.

So we need to be extremely careful working within the client system that we don’t inadvertently “adopt” a client instead of really focusing on our real client. The more critical point also is that once we have identified our true client, how do we ensure that we keep this client/consultant relationship? That is the subject of a future blog.

I spent a portion of my career traveling the globe, “fixing” projects that were either underperforming or failing for a major systems integrator. One of the most stark examples of getting the client wrong  was a project in a South American country  for an AFIS (Automated Fingerprint Identification System) project. The operator of the system was this country’s federal government agency responsible for the issuance of the “Cédula de Ciudadanía”, in essence your citizenship card.  The funder of the program however was not this government but an agency of the US federal government, known as the DEA. The objectives of the program were very different depending on who you thought your client was. One had the objective of uniquely identifying their citizens to allow for votes, taxes and social programs. The other was looking to create a knowledge repository of identities for criminal investigation.

When the project was reviewed, the operator of the system was getting the features and functions they were requesting, but the entity paying the bill was about to cut-off funding to the program. What was wrong?  The local team forgot who their client was. The client was the person who commissioned the work and was authorizing the payment of the fee.  The DEA. As a by product of meeting our client’s objectives, if we could solve the requirements of the operator, then that was a bonus. In some cases we could express back to our client, the advantages of enriching the solution with operator-requested features to enhance adoption or speed roll-out and generally they were accepted and paid for.  But it took a “reset” of the project to get focused back on what the real client wanted for the project to “succeed”.

I say “succeed” in quotes because the core purpose of the system was the unique identification (once) of each citizen and the issuance of a Cédula, which was used for everything from opening a bank account, to obtaining a passport , to getting your children enrolled in school.  The subsequent use of this data was for the original client to process. The problem was that all you needed to get a Cédula was a finger that did not exist already in the database and it turned out to be pretty easy for the less squeamish people who did not want to be in the system to either buy one or take one that wasn’t theirs. The program was disbanded.

Who is your client? Apply the fingerprint test.

Large projects automatically generate their share of humorous events and mishaps. The above statement was put into a dialogue box in  a program by a developer for the simple reason to mess with the QA & Testing group as a joke. For additional effect she added a randomizer that sometimes continued and sometimes quit on any action. Developers generally optimistically see the glass half full, QA always pessimistically see the glass half empty and architects of course simply know that you need a glass ½ the size for things to be perfect.

The result from QA, 9 logged and documented bugs.

1. Priority 1 bug – system did not “continue” as required

2. Priority 1 bug – system did not “quit” as required

3. Priority 3 bug – User Text confusing

4. Priority 3 bug – Test case ambiguous

5. Priority 1 bug – Any other key to quit works, any key to continue fails sometimes.

6. Priority 2 Tech QA bug – Developer did not seed RAND{} function , will not produce true random output.

7. Priority 2 bug – Function not documented in functional specification – Change Request required

8. Priority 3 bug – “Any key” “Another Key” function inconsistent with other program exit patterns.

9. Priority 3 Tech QA bug – code does not use standard IO library.

Just no sense of humor …

I was really looking for #1 – “Ah you’re just messing with us” but it never was logged. The learning from this humorous event (or attempt at it), is that above all the team needs to keep perspective. If something is silly, call it that because it just might be a joke or if not, still worth laughing at….

When I reached 1 Million mile status on both Air Canada and Delta airlines, I stopped counting. Suffice it to say that I have travelled a great deal. While there are advantages and disadvantages to travel, one enduring benefit is the ability to meet new people. When you join the higher echelons of the frequent flyer programs, it is rare to be travelling coach. I have had the opportunity over the years to be “seat-mates” in first class with former Canadian Prime Ministers Kim Campbell and John Turner, Former Premier (Ontario) Bob Rae, Goldie Hawn http://en.wikipedia.org/wiki/Goldie_Hawn , Ivana Trump, James Belushi, a host of international CxO’s and of course hundreds of road warriors like myself flying on a frequent flyer upgrade coupon. On a short flight it is pretty easy to ignore your seat-mate but add a few hours of flight time and there’s a pretty good chance you will get to know your neighbor.

Consultants when working with their clients progress from unknown/untrusted to “some rapport” to “open communication” to “trusted”. It is a process. The better we are at developing rapport, the better we are at communicating, the faster we will progress along the path to become a trusted advisor to our clients. We can add the most value as a trusted advisor.  I am pleased to say that many of my clients look upon me as a trusted advisor and in some cases I have retained that trust over decades. It is not a status that is granted easily and it is one that must be earned.

I arrived at LAX and got on a flight for Toronto, upgraded to first class as usual. I took my seat and a moment later was joined by Goldie Hawn in the seat next to me. She turned to me, looked me right in the eye, gave me a big smile and said “and you are…?”. I replied. “Well Hi Ian, I guess we’ll be travelling together, I’m going up to Muskoka, we have a place there and ….” And the multi-hour conversation started. So for the consultant in me I had just received a few tips from a world expert in establishing rapport…

– Initiate the conversation

– Start with questions to show you are interested

– Look them in eye, be friendly

– Tell them why you’re there.

In about 60 seconds, I went from being dumbfounded that I was sitting next to Goldie Hawn, to completely at ease, as if we were old friends just travelling up to the cottage for the week. She was showing genuine interest in my life, my concerns and was casual and open about her plans for the week. An hour into the flight I realized another key consulting skill at work.

Goldie was asking way more questions than answering them. By doing so, the conversation was really in her control. Pleasantly, casually but the topics and direction of the conversation was really of her choosing. I wonder how many times as consultants we end up in defensive positions, being peppered by questions instead being able to get to the core issues simply because we don’t control the direction by asking more questions.

– Ask questions to control the flow and direction of meeting.

Goldie would ask questions that required thought and complex answers, no simple binary yes/no’s. Example: Tell me what you like most about living in Canada. This provides the opportunity to talk more, provide more insight and potentially find new areas of discussion. We wandered all over the map on discussion topics during the flight. The counter example would be: “Do you like living in Canada?” that elicits only as yes or no answer.

– Don’t ask questions that have binary yes/no answers. Ask questions that require more input. How to feel about? What do you think about? Questions that allow them to give you perception not just facts.

As consultants, I think we can all learn from Goldie. I suspect there are very few people on the planet that after seeing her in on TV, in a movie or had the privilege of meeting her in person could not feel some sort of connection. By the way, yes she is just as funny and just as beguiling in person as she appears to be in the movies.

In contrast 2 of the 3 notable political figures I have travelled with were effectively inert making me think that if Goldie had been Canadian and interested in politics instead of Hollywood, she would have been our Prime Minister for many, many years.

The power of establishing rapport…

Today we have lots of methodologies. Lots and lots of them. They give us process, they define artefacts and deliverables, they provide roles and governance and they provide lifetime employment for “gurus” to write bookshelf straining tomes to explain them. For the most part, they are all good and in some other ways they uniformly lack a key component. I have invented this missing component. It is called the Bonaparte-Drake Methodology Adapter. (BDMA)

It is built on 2 premises from its namesakes.

"The torment of precautions often exceeds the dangers to be avoided.” – Napolean Bonaparte

“There must be a beginning of any great matter, but the continuing unto the end until it be thoroughly finished yields the true glory.”- Francis Drake

For the most part, the adapter injects two missing components into many of today’s methodologies.

They are:

Courage

To complete a risk analysis, yes but to look very, very closely at the potential impact of that risk should it be realized and to not overstate it.  This allows you to think broader and deeper than you did before.

“what if we just scrap that module and start again instead of tinkering with it” . Bonaparte would ask you;” what are the real dangers of just starting again?”. Is it really that heinous? Will it really put you months behind schedule or are you just afraid of taking it on?

Evaluate the time you spend thinking about doing something against the actual effort of doing it and perhaps just throwing it away if it didn’t work.

I recently led a project for a financial services company where some complex business rules for the adjudication were being discussed. We also were to discuss the best choice of business rule engine for the rules to be built in. One of my developers offered an opinion in the meeting. “Why don’t we just do it in BizTalk?” he said. “Why?” asked the client. He said “Well while you were putting the rules on the whiteboard, I coded them. It’s done.” and he demonstrated it. Courage.

Process is good, methodology is good but don’t let it extinguish the spark of innovation and better ideas by being too cautious.

Tenacity

“Thoroughly finished” is not just finished. It’s tested, it’s stress tested, it’s performance tested, it’s user tested, it’s documented completely, it’s peer reviewed, it’s got great code quality, it’s something that you want pull out a source listing for 40 years from now and show your grandkids. It’s making that better design work. It proving that the design was better. It’s innovation to just raise the quality bar just one more notch.

Following a process is not just getting a “tick” in the box besides the artefact deliverable.  The deliverable if you’re going to do it, needs to have real value. Value to either the next step in the process or value for reference.  On some artefacts, people tend to show some tenacity. I have seen some Use Cases that are well-developed, complete and ready for Analysis. But have you ever read a Use case Survey? Yes it’s a key artefact of the Unified Process and if it exists at all in most projects, it is rarely accurate or usable. It is for most, just a “tick” in the deliverable box.  What would Francis Drake have to say about it? Make sure it’s thoroughly finished or just get it out of your plan altogether. In a half-baked form it is completely useless for its intended purpose. 

Some  years ago I was asked to review the architecture and deliverables of a very large integration project that was “in trouble”. Every artefact was checked in, every artefact was dutifully signed off and upon my review, every artefact was woefully incomplete.  Including my favourite description of a complex business process in a Use case. I will quote directly:

“Blah

Blah

Blah”

Thoroughly Finished. Tenacity.

So how do you plug my adapter into your methodology?  Well … that takes courage and tenacity.

An independent consultant at CERN from June to December 1980 proposed a project based on the concept of hypertext, to facilitate sharing of information among researchers and built a solution. When he returned to CERN in 1984 he saw an opportunity to join his hypertext solution with the Internet:

"I just had to take the hypertext idea and connect it to the Transmission Control Protocol and domain name system ideas and — ta-da! — the World Wide Web."

Tim Berners-Lee, the father of the world wide web and a consultant.

One of my pet peeves on consulting engagements is to hear another consultant say “Well I’m just a consultant” and give up on delivering potentially great value to their client.  As a consultant, it is exactly the opposite. In fact, I like the following definition of consultant.

“One who engages in professional matters and advises and influences the client at the client’s request for a fee”

Now pick out the key words in that sentence. ( no the most important word is NOT Fee)

• Professional – You are not there to do something that just anyone can do. A professional has standards of skill, is competent, properly qualified and experienced.
• Advises – What is the best way to do this in your opinion.
• Influences – Now that you have said it , convince your client why it is the best approach.
• At the client’s request – They hired you because they value your advice and ability to get them to do the right thing.

Most consultants are professional, most provide advice (some even good advice) but very, very few understand their professional responsibility to influence their client to adopt the right approach.

Let’s assume that the client hires you to do an assessment of their current database implementation, optimize it and get better performance. A Bad consultant reviews it, fixes it and makes it go faster. An excellent consultant reviews it, fixes it, works to influence the client so that the best practices become part of the client’s environment so they don’t get in the same mess again AND makes it go faster both now and the future. That’s a professional.

To put it in perhaps more succinct terms. Assume you are a doctor. Your patient comes in coughing. Ah, you investigate and determine your patient has initial sign of Emphysema. You prescribe medication and send them on their way. – BAD DOCTOR

Assume you are a doctor. Your patient comes in coughing. Ah, you investigate and determine your patient has initial sign of Emphysema. You prescribe medication, you say “STOP SMOKING OR YOU WILL DIE!” , prescribe stop smoking aids, schedule follow-up verifications and send them on their way. – GOOD DOCTOR

We are professionals. We should be bound by the same professional ethos that does not allow us to ignore our responsibility to influence our clients as to what is the right approach.

Tim Berners-Lee could have said “I am just a consultant, they won’t care” but he didn’t. He influenced and inspired those around him to invest and fund the development of one of the most important technologies of the century.

Learn how to influence …

When I started my full-time career in IT (coop work terms excluded), I started as the CEO of my own company and was very successful for a few years. By doing so, you skip over all of the things you should learn about being a leader and simply take the role. In my third year running my own business, I was dealing on a daily basis with other CEO’s. Most of whom had spent decades achieving their success and were suspicious of the kid with fancy computers and software. I had hired a small staff of talented people and assumed that the title of CEO implied that I was leading.  I was wrong. I remember handing my father, my new business card with the updated Company logo and my name and title embossed into the surface. He took the card from me and handed it back. He said “Nice Title, but you’re only a leader as long as people follow. Is anybody following you?” They were not actually. Not because they didn’t want to, it was just that I wasn’t leading them anywhere.  It would turn out to be one of the important lessons of my life, to acknowledge that leadership is all about getting people to follow.

More than a decade later I was running a $100 million+ project for one the largest banks in the US. My team was over 200 and the client added another 250 people. We were costing our client almost a million dollars a week for the project. By this time , I had dramatically improved my leadership skills and was ready for a challenge of this magnitude. There are two learnings I believe that are worth sharing to future leaders of mega-projects:

1) Don’t just encourage teamwork, be a team leader. Define it, communicate it and then show it.

Teamwork – A manner of working in which people at all levels, share in the planning, directing as well as the execution of the work. In team activities, more ideas and better ideas, through the stimulus of personal interchange, come into consideration. The involvement of all team members in the decision making strengthens their commitment in execution also. Effective team work requires cooperation and thrives in a climate of freedom, openness and mutual trust, which results from careful self-discipline of expressed attitude towards others by each individual. Such a climate expands the contributions being made by everyone, which is advantageous for the project and satisfying for the individual.

2) Recognize and reward often

In this project I created the PETER award. Planning, Enthusiasm, Teamwork, Execution and Review.  The reward, a stuffed white rabbit that I bought for $10 in a gift store.

Every week the team nominated a worthy recipient and every week the project stopped, all 450 of us and headed for the cafeteria. (from two buildings).  The presentation was made and the PETER award could spend the next week in the cubicle of the deserving team member. It became a highlight of the entire week,

Peter would also show up in person,  to sit down with team members in their office, thank them for the hard work and encourage them. And PETER was….

The guy who had learned how to get people to follow him.