A Post On, Egads, Effort

images-5Regular readers of this space will know I am not a fan of the cult of efficiency that enraptures most businesses today. In my project management classes I stress that duration is the more important metric both the the professional and the customer.

That said, I would like to update the idea of comparative advantage as originally put forward by economist David Ricardo, but updated for the knowledge worker, especially the small firm. This idea seems to be about efficiency, but if one looks deeper, one will see that it is truly about effectiveness.

Adam Able is the owner/operator of a small IT consulting firm. Adam has been working in his industry for over 20 years and has a wealth of knowledge and domain expertise with the products with which he works. Because of this Adam, can slam out a new customized report in an average of two hours. He can also do an average migration of data in one hour.

Igor Egit is relatively new his profession; he has been at it a little over a year. Igor is not the brightest bulb in the drawer. On average it takes him three hours to deliver a new custom report, 50 percent more than Adam. While Igor does not suck at reports, he is a migration moron and it takes him four hours to develop a workable data migration, 400 percent longer than Adam.

This table shows the comparison.

  Igor Adam
Report 3 2
Migration 4 1
Total 7 3

 

If each does one report and one migration the total is 10 hours and the yield is two reports and two migrations.

Comparative advantage says that while Adam is better at both, and could theoretically do it himself in six hours, he is better off specializing in migrations and allowing Igor to do the reports, even though this runs counter to the idea of efficiency.

This table demonstrates the results of specialization.

Igor Adam
3 1
3 1
6 2

 

Notice again, that the yield is still two reports and two migrations, however, each received an hour of additional discretionary time. In addition, the total effort decreased to eight hours.

Now, some may argue that from an efficiency standpoint, it would be better to have Adam do both, since the total would be six hours not eight. What would that do to Adam’s leisure time? It would reduce it by four hours.

Looked at in this light, we can see that the question is: does it make sense for Adam to trade four hours of discretionary time in exchange for two reports from Igor. This is a value tradeoff that only Adam (and in a sense Igor) can make.

The trap is set, however, if we introduce the idea of a billable time rate to this example. Since it is unlikely that Adam’s rate would be three times that of Igor’s. Adam’s customers will either a) insist that they pay a reduced rate for Igor, or worse, b) insist that Adam himself do the work.

The traps is sprung! Adam, in the name of good service, will acquiesce to the customer. Likely, Igor will be out of a job; and Adam will miss more Little League games.

On Agile Project Management

Over the past few years, I have been hearing more and more about Agile development project management. For the most part the conversations have not been very positive.

This is not because I think there is something inherently wrong with Agile, but because those that espouse it have always tried to convince me of two things:

  1. Agile Development requires little to no planning
  2. There is no way to do agile development in a fixed price environment

You can imagine that I begin to shake violently at either of those ideas.

In the past month I have had two conversations that have corrected some of these misgivings. Mostly because I have come to the conclusion (confirmed by my conversations) that the folks with which I have had these previous conversations about Agile were full of shit.

Stephen Smith                 05e65fd

The two conversations – one with Stephen Smith, Chief Architect at Sage, the second with Rick Cobb, senior ERP consultant at Blytheco – have enlightened my thinking when it comes to Agile.

Rick had just taken a class and was kind enough to take me through the materials. I found that in many ways I am in alignment with many of the principles of Agile. For example, I really like the idea behind this:

image

Now, I would enhance the idea of customer collaboration to a more broad idea of comprehending customer value. Indeed, one weakness of all of the project management methodologies I have seen is the assumption of customer value. In all fairness, it is difficult to integrate value into any methodology because of it subjectivity, but that is for another post.

My conversations have led me to a few conclusions, all of which I am open to change based on more learning.

  • Agile is probably not for ERP implementations. While I certainly see Agile working in many other places (some noted below) the actual implementation is not one of them. The reason is that ERP projects tend to be more holistic in nature. For example, you cannot get the full value from an inventory tracking process without having first set up a properly structured general ledger. Agile call for prioritizations that make no sense in the context of ERP.
  • Agile makes a ton of sense for CRM projects which a normally more development related than ERP. With ERP, ultimately debits must equal credits (i.e., conform to GAAP), with CRM there are no rules.
  • One area where Agile could make sense for ERP would be in dealing with change requests and change orders. Often, these are mini-development projects and therefore Agile might be quite effective. I say might because on small engagements, some of the change requests might be so small as to only need an adjustment to the statement of work.
  • Another area where Agile excels is in communication. The daily standup meetings and one to two week scrums have some excellent communication touch points built in. I hope that when Agile is implemented that these processes are truly adhered to. There are definitely some things that Agile can teach us about better communications.

Ultimately, I think Agile is very much in line with the concept of results oriented project management that I presented in this space a few weeks back. This gives me some hope for being able to integrate some of the best idea from both methodologies into one more coherent approach.

My thanks again to Stephen and Rick who contributed to my thinking about this post.

Results Oriented Project Management

The traditional project term hierarchy as defined by the Project Management Institute is this:

(Program)
    Project
        Phase
            Activity
                (Task)

They are defined thusly:

  • (Program) – a group of related projects
  • Project – a temporary endeavor undertaken to create a unique product, service or result
  • Phase – a collection of logically related project activities, usually culminating in the completion of a major deliverable
  • Activity – an element of work performed during a project which has an expected duration and assigned responsible person
  • (Task) – an element of work performed in the completion of an activity which has an estimated level of effort and assigned responsible resource

The use of parentheses in the above indicates that programs and tasks are optional in project management. The remaining three (project, phase, and activity), however, are required elements of any properly constructed project.

In my work with Sage implementation partners over the past nine years, I have become more and more convinced that this structure is lacking in heavily knowledge-based projects such as software implementation. Furthermore, I think it pertains to all fields of knowledge work, such as: an accountant conducting an audit or a completing a tax return; a lawyer trying a case or processing a matter; and even a architect designing a building.

To correct this, I have been tossing an idea around in my head for over a year now and I think it is ready to be presented and criticisms levied. I call it results-based project management.

In short, it replaces the above mentioned hierarchy of terms with this one:

(Program)
    Project
        Objective
            Result

The definitions of program and project remain the same, but in place of phases, I substitute objective and in place of activity, result. Here are my definitions:

  • Objective – a collection of logically related results summed to explain  exactly what outcomes (not goals) of project will be
  • Result – a discrete element of output that has an assigned responsible party and an estimated completion date

A result can optionally have a resource assigned if it differs from the responsible party and an estimated amount of effort. Please note that the estimation of effort is for resource planning purposes only and it not intended to be used in conjunction with a timekeeping system.

Please note the shift from words used to describe actions (activity and task) to words that descript outputs (objective and results). This can be thought of as a shift from efforts (verbs) to tangible results (nouns). This is in keeping with the reality that customers by results not efforts and certainly not hours.

Reversing the flow of the hierarchy leads to an easy-to-understand definition for project completion. The sum of a group of related results can be thought of as an objective. The sum of all the objectives can be thought of as the project. It is when all results have be completed and all objectives have been met that the project is considered completed.

The challenge is, of course, defining all the results. This is what scope is all about and that is the subject of another post.

That is the idea in brief. I await your critiques.

N.B. – Two other definitions are helpful in understanding this post.

  • Responsible party – the person who is responsible for making sure the work is completed by the estimated completion date.
  • Resource – the person who does the actual work.

Often times these two are the same person, but that is not always the case.

Ed Kless Is Wrong

Once again, the self-proclaimed Defender of the Timesheet and Champion of the Dissenters, Greg Kyte, is at it again. This time he takes me on rather than Ron Baker of VeraSage.

Dear Ron,

Quite awhile ago, I sent the following letter to the Journal of Accountancy, but apparently they were too scared to print the truth. Enjoy as I expose the falsehood of your co-conspirator, Ed Kless.

In April 2010 the Journal of Accountancy published the article, Project Management for Accountants by Ed Kless. Although the article contained a significant number of words, many of those words created lines, and if one reads between those fabricated lines, one may find the same offensive subtext that I found. The author is waging a guerilla war – not against gorillas, but against the accounting profession. Project management is for ignoble professions such as contractors, engineers, and doctorate-level pharmacology researchers. Project management may be good enough for those and other financial Cro-Magnons. We accountants, however, are the progeny of a dignified tradition, and our collective pecuniary prowess has led us as a community to a near-universal acceptance and usage of the financially sophisticated and elegantly simple concepts of the billable hour and the timesheet.

Mr. Kless’ approach to project management is his attempt to rob our profession of the fringe benefits that accompany the billable hour and the timesheet. In his article, Fast Eddie lists eleven essential components of a scope statement. He advocates the use of a scope statement because it is designed to limit “scope creep”; however, he ignores that fact that under the billable hour paradigm, scope creep creates revenue. Ergo, Fast Eddie is trying to decrease your firm’s revenue, and if you consult your accountant, she’ll verify that revenue is a good thing.

In his opinion, all assumptions between a firm and a client are to be clearly enumerated. Mr. Kless exhorts us to “answer the question, ‘What should we not leave unsaid?’” But since I bill by the hour, there is only one assumption that I can’t leave unsaid—the assumption that if I work on an engagement for an hour, the client is going to pay me for an hour.

I actually liked his idea of maintaining a “future project list.” It’s a list of possible projects and major tasks that will be deferred until the future … like when I need more billable hours.

He argues that constraints need to be brainstormed and specified. Constraints are limitations and restrictions that could hinder the efficiency of an engagement. The article states that constraints are “risks in waiting.” Don’t look at constraints as risks in waiting; look at them as semi-avoidable wellsprings of cash flow.

Possibly the most offensive part of this article was the following assertion made while discussing how to calculate percentage of completion: “Measuring the completeness of your projects by hours billed is akin to listening for the smoke detector to determine when your cookies are done. The alarm only goes off when it’s too late.” This is blatantly invalid. The beauty of using billable hours is that we don’t need to measure completeness. Billable hours and timesheets are actually like cooking with the Ronco Rotisserie and BBQ Oven: “Just set it and forget it!”

Once again, Greg demonstrates that he is quite deserving of his self-developed moniker.

Insights Session – Creating a Great Scope Document

On Monday, May 17th at 1:15pm at Sage North America’s annual partner conference, Insights, I will be presenting a session entitled Creating a Great Scope Document (GEN55)

This session will be dedicated to the possibility that we can create great scope documents for our customers and that by doing so we will significantly increase the probability of success. Creating such scope documents is hard work and not for everyone. It requires us to think differently than we have in the past. You are hereby invited to open a dialogue on creating such scope documents.

image

The objectives of this session are to understand the triangle of truth and elements of scope document.

For those of you who plan on attending the session, please comment below with any thoughts or questions that you would especially like me to address during our time together.

April is turning out to be a big month

First, I received word that an online comment I made on a Harvard Business Review blog post would be printed in the magazine.

image

For those of you that can’t make it out, my 15 seconds of fame reads, “Business ain’t science.” I told the copy editor that I had more to offer than that and that I usually am grammatically correct, but they did not seem interested. “No, your thought really says quite a lot.” Uh-huh…

Next, my article on using project management to replace the timesheet finally made it into the Journal of Accountancy. Please comment there as I would love to get a big long string going.

Could it be that the Mets getting out of the gate strongly? I can only hope!

My Sessions at Sage Insights 2010

A few of you have written to me to ask about what sessions I am facilitating at Sage Insights 2010. Thank you for the vote of confidence as I assume this is because you would like to attend them, not avoid them. In either case, here they are:

Code Day & Time Title

PRE19

Sunday, 8:00am – 5:00pm

Sage Consulting Workshop

GEN55

Monday, 1:15pm – 2:15pm

Creating a Great Scope Document

GEN23

Monday, 2:30pm – 3:30pm

Managing an Engagement From an Issues List

GEN54

Tuesday, 3:15pm – 4:15pm

Enhancing Your Customer’s Experience

GEN53

Wednesday, 9:15am – 10:15am

Consulting and the Crisis of Self-Esteem

GEN52-1

Wednesday, 1:30pm – 3:00pm

Creating the Firm of the Future (Part 1 of 3)

GEN52-2

Wednesday, 3:15pm – 4:15pm

Creating the Firm of the Future (Part 2 of 3)

GEN52-3

Wednesday, 4:30pm – 5:30pm

Creating the Firm of the Future (Part 3 of 3)

GEN58

Thursday, 8:00am – 9:00am

Creating a Partner-Based Service Level Agreement

GEN22

Thursday, 9:15am – 10:15am

The Parting Glass: So What and Who Cares?

FORD – a model for consulting

A little over three years ago, a dialogue began in one of my consulting classes that I teach for Sage. The conversation focused around the levels (I am not convinced levels is the right word) of consulting. In the end, the group proposed the following four levels: Findings, Options, Recommendations, and Decision. Serendipitously, this yielded the acronym FORD. (I personally own a Honda Pilot.)

This model has served me quite well over the last few years, so I thought it worthy of a post wherein I will briefly define each level and provide some overall thoughts about the model.

  • Findings – these are the issues (problems, opportunities, and desired results) that the consultant uncovers through a question and answer process, referred to by most as discovery.
  • Options – these are the different possibilities that the consultant proposes for solving the uncovered problems, seeking the opportunities, or achieving the desired results. A great consultant always includes, “Do nothing,” as an option.
  • Recommendations – this is the option (or options) that the consultant believes would be the best course of action for the customer. Making recommendations would usually include a list of advantages and disadvantages (pros/cons, positives/negatives, strengths/weaknesses, whatever you want to call them) of each options and a rationale for why the option(s) was(were) selected.
  • Decision – one of the various options or a variation of the options is selected for implementation.

A few observations about the model:

  1. Each incremental level increases the level of risk on the consultant and requires an higher degree of knowledge. Since risk and knowledge required are factors in setting price, an engagement to just collect findings will be less expensive than an engagement to present options and an engagement to present options will be less expensive than an engagement to provide recommendation.
  2. If you are making the decisions you are not a consultant, but what Peter Block would call a surrogate manager. He defines this as “a person who acts on behalf of or in place of a manager.” Surrogate manager-hood is not bad in and of itself, but it is way more risky and deserving of a premium price.
  3. Being a consultant or a surrogate manager is a strategic decision. Some people may choose to never enter the fray as a surrogate manager and only remain in the role of consultant. This leads to what could be another blog post – the paradox of consulting – which is that consultants are paid to not make decisions.
  4. It is critical to have a conversation early on with every customer or prospective customer as to the level of consulting in which they would like to engage you. Failure to do so causes not only pricing problems, but myriad of other problems that are out the scope of this post.
  5. I believe that all professionals are consultants of some kind. Doctors are consultants on the anatomy and physiology of the human body; lawyers, on the law and legal system; accountants, on accounting practices, etc.

I welcome any comments and any suggestions on a better term than my proposed levels.

Highlights from Issues List Management Session

On May 12, 2009, I presented a session at Sage’s annual partner conference, Insights. The session was entitled Issue List Management (or how to replace your time sheets with something that actually matters to your customers).

First up are the slides from the session.

Next, here are the video highlights and the document for downloading.

 

And finally, the big finale! This is only for those of you who are radicals (like me) – a song which I believe demonstrates the immorality of tracking your time.

Virtual Seminar: Basics of Project Management

I will delivering a seminar on Second Life on the Basics of Project Management through the Maryland Association of CPAs on Friday, July 17, 2009 ay 1pm ET.

Description:

This course is designed as an introduction to project management for individuals who are involved with projects (customer engagements) but have no formal project management training.

Objectives:

Help the participants gain some basic project management skills

Major Topics:

  • The difference between goals and objectives
  • Three foundational assumptions of every project
  • The triangle of truth
  • A basic understanding of risks
  • The change request

Who Should Attend:

Anyone involved on projects (customer engagements)

Prerequisite:

None

If you plan on attending, please register and make sure you have created your Second Life avatar in advance.