Tag Archives: project-management

Time Blindness

On Budgets

What function do budgets serve?

In a case where there are well-known basic requirements, and highly variable-solutions, a budget is essential to curb the tendency to put wants ahead of needs. Take, for example, an automobile purchase. All you need is four wheels. Maybe you need four doors if you have two kids, or a minivan if you have three kids, but you certainly don’t need a sunroof, or a hemi, or a self-parking car. These are luxuries. Maybe you can afford to splurge a bit, but the budget knows there are other needs that take priority, like food, mortgage payments, and utilities.

When we try to take this concept of a budget to the workplace it breaks down. In the workplace, budgets serve one of two purposes: (1) flagging corruption, and (2) investment payback.

Purpose 1: Flagging Corruption

When we know about how much money it should take to do a job, we give the responsible person a budget. “Marty, we’ve been attending conferences in Las Vegas for 30 years. We know it costs about $X, so you have a budget of $X and $Y for contingency.” As long as Marty stays within that budget, keeps his receipts, and can avoid having the escort service charges showing up on his company Amex, he’s good to go. If his expense report comes in at twice the expected amount, then he has to justify it.

When you know how much something should cost, this is an efficient model. It delegates spending to the individual and only requires minor oversight from the accounting department.

Note that the budget wasn’t set based on how much money was in the bank, it was based on historical data, and the company decided there was a payback to send Marty to Las Vegas. That’s a fundamental difference between home and workplace budgets: at home we frequently buy stuff with no perceived payback, but at a company every expenditure is an investment. That’s why the function of budgets at home and at work are fundamentally different.

Purpose 2: Investment Paybacks

When you don’t have good historical data on a planned expenditure, accounting still needs an estimate. Estimates feedback expected expenditures to whoever is managing the cash flow. Budgets are the present-cost of the expected payback, with interest.

When a company looks at starting a new project, whether it’s done internally or subcontracted, first they get an estimate. Then they compare the estimate to the expected payback, and if it pays back within a certain time-frame (usually a couple of years, but sometimes as short as a few months), they go ahead with the project. However, since projects are, by definition, something you haven’t actually done before, everyone acknowledges that the estimate won’t necessarily be accurate. They will generally approve a budget with an added contingency. They’ve done the calculations to make sure that if the project comes in under that budget, the payback will make the company (and the investors) money.

As the project progresses, the project manager needs to track the actual expenditures against the expected expenditures, and provide updated estimates to accounting. If the estimate goes higher than the approved budget, management has to re-evaluate the viability of the project. They might increase the budget if the payback is good enough, or they might scrap the project.

Tying Incentives to Budgets

For home budgets, it’s implied: if you stay within your budget, you’ll make sure to satisfy all your needs, and you’re less likely to find yourself in financial hardship. You have an incentive to stay on budget.

At work, lots of people have their bonuses tied to “performance-to-budget”. If we’re talking about the first purpose of workplace budgets (flagging corruption) where historical data provides a solid prediction of what something should cost, then it makes sense to evaluate someone on their performance to that budget. On the other hand, if we accept that project budgets are based on rather inaccurate estimates, then measuring someone to a project budget isn’t very efficient.

In fact, it leads to all kinds of behaviors we want to avoid. First, people might tend to over-estimate projects because that will raise the budget. This might prevent the company from pursuing projects that could have been profitable. Secondly, project managers tend to play a “numbers game” – using resources from one project that’s going well to pad another project that’s going over. This destroys the accuracy of your project reports; now you won’t know which initiatives really made money. Third, the cost will be evaluated at the end of the project, but the payback continues over a longer time-frame. The project manager will tend to make choices that favor lower cost at the end of the project at the expense of choices that offer higher long-term payback.

Everything I’ve read suggests that (a) project managers have very little influence over the actual success or failure of a project and (b) in any task that requires creativity and out-of-the-box problem solving, offering a performance-incentive reduces performance because you’re replacing an intrinsic motivation with an extrinsic one. The intrinsic one is more powerful.

So why do we tie performance incentives to project budgets? Is there really any research that suggests this works, or are we just extrapolating what we know about purchasing a car, or taking a trip to Las Vegas? As someone who is intrinsically motived, I’ve found budget performance-incentives to be extremely distracting. Surely I’m not the only one, am I?

Beating Procrastination

2 Replies

I recently downloaded The War of Art: Break Through the Blocks and Win Your Inner Creative Battles (by Steven Pressfield) for my Kindle and blasted through it. It was recommended by Seth Godin, etc., and I figured I’d give it a shot.

First of all, I couldn’t help but notice the irony: certainly reading a book about procrastination is, by definition, procrastination. Or is it just sharpening the saw? Well, I had just finished pushing out FluentDwelling so a little procrastination at starting the next project is probably understandable.

Secondly, the book is well worth a read. If you’re an artist, writer, engineer, entrepreneur, or really anyone that does creative work on a daily basis, this book is like a shot of caffeine. He starts off by describing what he calls “the Resistance”, which he manifests as the ever-present enemy of all of us. It’s the collection of invisible forces that keeps us from starting.

It made me do a little introspection of my own Resistance. I know that the key is to start working. The biggest thing that keeps me from sitting down and starting work is anticipation of interruption. Certainly we already know the dangers of being interrupted while working, particularly if you need to get into “the zone” to be productive in your job. The problem is that the negative consequence of possible interruption became so great that the anticipated consequence of the interruption was worse than the anticipated reward of getting work done. Interruption is a physical assault. It feels like being punched in the gut, and even though I can take a few of those in the course of the day, a constant pounding wears me down.

What was the consequence? Entire days lost to quadrant 1 (or worse yet, quadrant 3) activities. When you work at a place where, if you wait 15 minutes, someone will call you with some “urgent” problem, then it’s too demoralizing to start working on the bigger tasks (or the bigger tasks only get done after hours and on the weekend).

I’ve only, in the past few years, realized how hard you have to fight for the right to work even in the workplace. Pressfield describes every day as a battle, and he’s right. The stakes are high. The enemy is relentless. Here are some of the tactics I’ve employed:

No instant messenger
Email notifications are turned off – I check email on my schedule
I work from a prioritized to-do list
I automate myself first – increase your own productivity, then help others

What are the worst productivity killers I’ve experienced?

Being asked more than once a day for a status report
Not having the tools to do your job
The Web – which is a nasty double-edged sword, because it’s a productivity multiplier

I don’t win this battle every day, but my win-loss record is improving. This book is one more salvo deep into the gut of the Resistance. I’ll leave you with this quote:

We were put here on earth to act as agents of the Infinite, to bring into existence that which is not yet, but which will be, through us.

Maybe that’s a prayer to say before sitting down at my desk in the morning. I look forward to doing battle tomorrow.

Upgrading a Legacy VB6 Program to .NET

Leave a reply

There is a lot of code out there written in VB6, running just fine. If you’re someone who has to maintain it, then at some point you’ll ask yourself, “should we just bite the bullet and upgrade this to .NET?”

There is, so far, no end-of-life issue on the horizon. VB6 applications will run on Windows 7, and Microsoft has vowed to support the VB6 runtime through the life of Windows 7. That will be a while, so there’s no hurry.

First, you need to do a cost-benefit to determine if it’s worth upgrading. That’s a pretty big task right there. What do you gain by moving to .NET? Certainly you gain a much richer ecosystem of utilities, libraries, persistence layers, test frameworks, etc. You’ll also find it easier to hire developers who have .NET on their resume. It’s pretty hard to find a copy of Visual Studio 6 these days, unless you have an MSDN subscription. .NET features like lambda expressions, LINQ, and reflection are also big productivity boosters if you spend the time to become proficient with them. These are all valid points, but they’re hard to measure.

You’re going to need to do some ballpark estimates. I’ve actually been doing some conversions lately, so I have some real experience to throw at it. Take any VB6 application, and it’ll take you 1/3 to 1/2 of the original development time to rewrite it in .NET with the same feature set (using test-driven development). That’s my estimate… do what you will with it. So, how much maintenance work are you doing, and how much more efficient would you be after the conversion?

So let’s take an application that took one programmer 6 months to write, and then you’ve been maintaining it in 50% of your time for the last year. So there are 12 months of development in the existing application. By my estimate you’ll need to spend 4 to 6 months rewriting. Let’s say you’re twice as fast after the conversion (if you didn’t have unit tests before and you use test-driven development during the conversion, the unit tests alone should make you this much more productive, not to mention the improvements in the IDE and the full object-oriented support). In that case, the payback period is 8 to 12 months of actual planned development. If you have that much work ahead of you, and you can afford to put off working on new features entirely for half that time, you’ll break even.

That’s still a really big investment. The problem is that you won’t have anything to show for it for half that time. It’s surprising how quickly management could lose faith in your endeavor if they a) don’t really understand what you’re doing and b) don’t see any tangible results for months.

There are alternatives to the all-or-nothing rewrite. First, you can use a conversion tool to convert the VB6 to VB.NET. The one that comes with Visual Studio 2005 is notoriously bad, but some of the commercially developed ones are apparently much better. Still, given VB6’s laughably bad support for the object-oriented programming paradigm, the code you get out of the conversion is going to smell more like VB6 than .NET. It will get you done faster, probably more than twice as fast, so it’s still an option. However you won’t get a chance to re-architect the software or normalize the database, etc., in the process.

The other alternative to the “big rewrite” is to do the upgrade in an “agile” manner. Take some time to break the software into smaller modules, each of which can be upgraded in about one month or less. This will significantly lengthen the amount of time it takes you to finish the project, but you’ll have something tangible to show after each month. Most managers can wait this long. This approach has its problems too: you need to write a lot of code to interact between the VB6 and .NET code. It can be tricky.

Normalizing a Database

If you’re in a position where you have a database as a backing store, and you need to make major database structure changes, this must affect your decision. The “big rewrite” is the most friendly to database changes: you just write a single conversion script that upgrades the existing database in-place, and you write your new version against the new schema. You have a clean slate, so you can clean up all the crufty problems in the old schema.

On the other hand, if you’re just using a conversion tool to automatically convert from VB6 to .NET, you can’t change the schema.

If you take the middle road (“agile”), you can change the database structure at the same time, but it’s much more difficult than in the “big rewrite”. As you upgrade each module, it makes sense to modify the database structure underlying that module, but unless you’re really lucky, you’ll have parts of other modules left in VB6-land that are dependent upon database tables that are changing. That means you’ll have the same problem anyone without a really good data access layer (or object-relational persistence layer) has when they go to change the database schema:

You have a whole bunch of code that looks like this: sql = "SELECT MY_COL1, MY_COL2 FROM MY_TABLE JOIN..."

Assuming you don’t have unit test coverage, how do you find all the places in your code that need to be changed when you normalize MY_COL2 out of one table into another? Of course you can start with a search and replace, but if you really have a database normalization problem, then you probably have duplicate column names all over the place. How many tables have a column called CODE or STATUS? There are many pathological cases where a simple text search is going to find too many matches and you’ll spend hours tracking down all the places where the code might change just because of one column being moved or renamed.

The most pathological case is where you have, for instance, two columns like CONTACT1 and CONTACT2 in the same table, and somewhere in the code it says sql = "UPDATE MY_TABLE SET CONTACT" & ContactNumber & " = '" & SomeValue & "'". You’re doing to have a hard time finding that column name, no matter what you do.

You need to develop a smarter system. I’ve tried a couple of different approaches. I tried one system where I auto-generated unique constants for all of my table and column names in my database, and then I wrote a script that went through my source code and literally replaced all of the instances of table or column names inside of strings with the constants. When I changed the database, I regenerated the list of constants, and the compiler was able to catch all the dependencies. Unfortunately, this method has some deficiencies: the resulting SQL statements are more difficult to read, and when you go and make changes to these statements you have to be disciplined enough to use the generated constants for the table and column names, or you break the system. Overall, it saves a lot of time if you have a lot of database changes to make, but costs extra time if you have to write new code.

I tried a different variation of the system where instead of replacing the table and column names in the string directly, I added auxiliary statements nearby that used the constants for the table and column names, and these would generate compile errors if a dependency changed. This made the code easier to read, but had problems of its own.

I don’t have a perfect answer for this problem, but if you have any SQL strings embedded in your legacy VB6 application, and you want to do big changes to your database, I can tell you that you must build a tool for yourself.

Summary

If you really must convert your application from VB6 to .NET then make sure you go into it with your eyes wide open. Engage management in a frank discussion. Make sure you get a strong commitment. If they waffle at all, walk away. The last thing anyone wants is a half-converted piece of software.

Still, I’m here to tell you that it is possible, and if you do your homework, there can be a real payback. Good luck!

Bob’s Clues to Doomed Project Managers

1. “We just need to buckle down”

“If I had a nickle for every time a PM talked about buckling down,” said Bob. “What this really means is he doesn’t see any obstacle that can’t be overcome with lots of unpaid overtime. I imagine old King Tut buildin’ his pyramid talked to his people a lot about buckling down.”

“The problem,” said Bob, “is that they get addicted to it. The solution to every problem on every project is to buckle down. They don’t learn to plan it better next time, have the parts ordered a week earlier just in case, have the drawings reviewed by someone else, or whatever. Why bother when you can make it someone else’s problem?”

2. “We’re a little behind, but I think we can make it up”

“On the surface, this sounds a lot like the buckle down thing, but there’s a subtle difference. In fact you’ll often hear them used together, like we’re a little behind schedule, but I think we can make it up if we just buckle down. What you’ve really got on your hands here is an incurable optimist. The best predictor of future performance is past performance, but this fella thinks yeah, it’s been going bad so far, but for no reason whatsoever, I think it’s about to turn around and go the other direction.

3. “We know you like to do things the right way, but…”

“I’ve been around a few years now, and I find I’m now the guy they call in to go fix stuff that’s already behind schedule and over budget. So I really think it’s great when they pull you into their office and say we know you like to take the time to do things right, but we’re way behind schedule and over budget here, so take whatever shortcuts you can to get it to work, and we’ll have to fix the rest on the next job. The irony of this is apparently lost on the poor doomed PM, because it’s almost always the rushed, half-assed job that he told the guy before you to do that got him into this mess in the first place.”

4. “We didn’t have time to…”

“This is my favorite,” said Bob. “The customer comes to you and says the widget doesn’t do what he wanted it to do, and you say of course we can do that!… but let’s take a look at the spec to see if it’s supposed to be included, or if it’s an extra. You call the PM and he says, I remember them saying in a meeting they didn’t want that, but we were over budget and behind schedule so we didn’t have time to update the spec. Then you end up doing days of rework to make up for the 30 minutes of typing he saved. The PM’s whole job is to plan, document and manage the scope of the job. If he wasn’t doing that, who was managing the project?”

Others?

There were some other clues I just can’t remember, but those were the ones that stuck with me. Does anyone have clues of their own they would like added to the list?

Contact and Coil

Nearly In Control