Project Zen

Years ago, I started off my career as a standard developer and quickly became aware of ones natural tendency to place projects on a spectrum of good/bad:

“I get to use the latest technology? I love that, so let’s nudge the needle to the ‘good’ side, please! Oh, but I have a complex, 30 page requirements document to follow? I hate documents, so we’d better put the needle back where it came from…” Many developers do this and it seems normal, however, I’m trying to become a consultant. Now and then, I may be somewhat dissatisfied with the nature of a project but if I want to complete my transition from developer to consultant, I must learn to work on any project, in any environment to do my best work.

The Judgement Process

When evaluating a project, each piece of information becomes a property used to describe that project (“VB6 app”, “agile”, “highly contentious” etc.) and those properties pass through a filter where I determine how to feel about them (“boring”, “easy”, “honorable” etc.). Then, I weigh those values and assign a score on the spectrum of good to bad and this is completely natural. When the client asks “what’s it going to be like to add some extra functionality?”, I bring these feelings and opinions to the table. Sometimes, who does the work tends to determine the solution, since I might try to minimize the amount of time I have to spend with VB6.

The Real Issue

So what’s at issue here? The issue is that I’m making this about me when it’s really not. As a consultant, I’m not paid to hold opinions based on personal beliefs and desires. In fact, I’m paid not to. Objectivity is why a company brings in consultants. By holding personal beliefs about a project, you are, by definition, violating that objectivity.

What If?

What if instead, when evaluating a project, we stopped right before we passed the properties through our filter. Isn’t the project in a much more “real” form? Aren’t the properties more objective?

What if we listened to those properties? What if we inferred knowledge about the client from the project? What if the fact that the project is in VB6 means something about the organization? What if we made that a statement about the people themselves?

What if we passed those properties through a filter, but not one of our own making? What if we painted every property as “valuable” or “necessary”? What does that say about the organization now? What does it say about the people?

Project Statements

If we can modify our evaluation process, playing with the filters we put a project through, it really becomes something new. Here are a few points to keep in mind:

•A project isn’t good or bad. A project is.

•A project exists because it results in a net increase in value. If it did not, it would not exist.

•A project has the attributes it does because those attributes are the ones that serve the organization best.

•A project is a mirror of the organization and the people that make it up

Bringing It Home

So how does this relate back to my satisfaction? Quite simply, it’s important to not judge the project or the organization, but instead realize that you are in the position you are because you are an observer of the problem. If you want to truly help an organization, you must be able to look past your own judgements and see the problem you are trying to solve as it exists in reality, which includes how it fits within the organization. Once you do this, you are better equipped to provide help. Helping the client in a more real way is, so far, the best way I have found to bring satisfaction to my life. Help them, help yourself.

Originally posted by Camron Bute at Camron Bute’s Blog