Selling the Dream

I used to be acquainted with someone whose motto for running his business was "Sell the dream but deliver the reality." Does that make alarm bells go off in your head? It does mine.

We all have dreams. Maybe it's buying a house or getting student loans paid off. Perhaps it's a vacation to somewhere exotic. My dream car is a Range Rover Evoque but it is just that, a dream car because at this point in my life I can only afford one in my dreams. Dreams are where our every wish and desire are fulfilled. Sometimes dreams do come true but usually through a lot of hard work and determination.

Now if I went down to say, CarMax, told them I wanted a Range Rover Evoque, had $25,000 to spend, and they said, "Okay" I'd be pretty excited. However, if when I showed up to pick up the car they handed me the keys to a Honda Accord, I'd be pretty upset. Just to be clear, I drive a Honda Accord, his name is Eric. He's unassuming on the outside but slip into the driver's seat, wrap your hand around the six-speed manual, and you'll soon learn there's more than meets the eyes. In other words, it's a great car. Nonetheless, if I'm promised one thing but given something different - or worse, inferior, I will not be a satisfied customer and in fact I will feel cheated.

Besides the obvious that the customer doesn't get what they expected, doing business this way establishes a relationship built on lies from the very beginning. If they're willing to tell a big lie, no doubt they're willing to tell little lies the entire time they're working together. Unfortunately by the time the client figures out what's going on it's too late.

In a perfect world, business ethics wouldn't even be a topic of conversation but I think this behavior is reprehensible. And I'm proud to say that I think my current employer is the most ethically sound company I've ever worked for both in the ways they interact with clients and how they treat their employees. I digress. I personally don't ever want to get burned so it is my desire to put out into the world that which I think can help others.

Here are some things to look out for to make sure you don't end up locked in with a snake oil salesman:

1. Promises to do a lot more than any other bidders
2. Promises to do the project for a lot less money than any other bidder
3. The proposal is extremely vague
4. The proposal is so long you don't know what it's talking about or is full of a lot of flowery language about how wonderful their company and process is
5. Any part of the proposal seems to be too good to be true
6. The vendor has no concerns about meeting any of your requests (not to say they can't be fulfilled)

What you can do to protect yourself:

1. Solicit multiple bids and compare them in detail, not just the price quote
2. Insist on extremely detailed contracts*
3. Demand transparency
4. Get references for recent, comparable work. Check them and look at the finished product if at all possible
5. Listen to your instincts - If you think you're being lied to, you probably are

* I recommend watching this video. It's aimed more at the vendor than the client but the advice is spot on and really, contracts protect everyone. Note, there is a fair amount of vulgar language and there is one metaphor used that is poorly chosen. Nonetheless, I think the good outweighs the bad.

Don't Judge a Book By Its Cover

We teach our children not to judge books by their covers. Literally, when they're young and start picking out books to read themselves, not to do this. A book may not have any eye-catching artwork. It could be worn and tattered. The plot introduction on the back might be unappealing. And so we try to instill in them that before forming an opinion about a book you should dive inside and get to know the full story. As children age, this proverb takes on a broader meaning that we shouldn't make snap judgements about other people. Just because someone has tattoos and piercings it doesn't mean he's a felon. Just because someone is clean cut it doesn't mean he's a nice person or trustworthy.

And so all our lives we're taught not to jump to conclusions. Then we grow up, make a career in software development, and that all goes out the window. "How so?" you ask?

Estimates.

It seems most our work starts with estimates. Someone contacts us wanting a new website. They want to know how long it's going to take and how much it's going to cost. If we told them we'd let them know when we're done, they'd get up and leave immediately, laughing all the way. A conversation is had. Likely several conversations are had. The potential client might even have a pretty detailed outline prepared of what they want. If they have an existing site that they want redeveloped into something befitting 2013, we'll do an thorough analysis of it. Nonetheless, we still have to make a judgement call based on a cursory amount of information.

Is this a bad thing? Nah. I don't think so, and I'll explain why in a second. But, I want you to realize that that is what we do all the time as a matter of practice. Think about it. Turn that over in your mind. Chew on it.

Despite what our parents teach us about making snap judgements regarding books and people, we're actually trained to do that sort of thing all the time. The light just turned yellow - slam on the break or step on the gas? Sweetie-Pie wants to know when dinner will be ready. A guy named Big Precious is selling iPads out of his trunk. We spend hundreds of thousands of dollars on a home and even though we have inspections, you still don't truly know what's hiding behind the walls.

Still chewing? Even though we get a lot of practice at making calls based on the information currently available, isn't it still just a little crazy what we do? Saying this is how long a project will take and this is how much it's going to cost? Software development is some complicated sh!t. Technology is constantly changing. Requirements have ambiguity. There are hundreds of things that can happen to cause the most accurate estimate ever to be completely destroyed. Quoting the wrong numbers can not only spell the end of a business relationship but the end of the company.

I think it's messed up but I realize the client is just mitigating their risk. They don't have unlimited money and they don't have unlimited time. It really isn't unreasonable for them to know how much and how long.

There are many ways we can mitigate our risk too including:

1. Gather as much information as possible
2. Use what you've learned from previous experiences
3. Add in ample wiggle room

The big thing though is to be painfully transparent with the client once you crack that project open and dig in. Let them know your progress. Alert them ASAP when reality isn't matching up with the assumptions initially made. If an unexpected complication pops up, sound the alarm. Let them get their hands on the product early so they're not surprised by anything either. Keeping the client informed gives you leverage to negotiate changes to the schedule and cost. The clients are people too. They know things happen sometimes but they deserve better than to be blindsided.

I'm probably not saying anything new here but I hope that I'm putting our process in a perspective that helps us to use it more effectively and keep from getting burned.

Your Website Is a Rubik's Cube

My coworker, @jakedowns, has a Rubik's Cube sitting on his desk. It seems to serve as a physical manifestation of the gears turning in his brain as he's working on solving a development problem. He's actually  pretty good at solving them and can usually do it in less than a minute.

On occasion, I've happened past his desk and noticed that it has been arranged in a checkerboard pattern. Last Friday I decided that he needed a challenge so I designed a pattern and told him to replicate it.

And he did! However, the pattern I provided was for only one face and his solution was for only one face. At the time, I made a joke that "the requirements were met but the purpose was not fulfilled" because I wanted the pattern to be displayed on all six faces.

At this, I set to work plotting out all six faces. It took me hours, literally, to figure out a valid solution extending the original pattern to all six sides. It was a great exercise for me. I learned that the pattern does not work when using the colors of opposing faces for the pattern (e.g. blue and green). I also learned that not only do I have to account for all eight corners, I also need to account that the thee colors on each corner are in the correct position relative to the other two. I also exercised my spacial reasoning skills quite a bit.

In the midst of all of this, I was thinking about how websites are like Rubik's Cubes. Designing and building a website isn't as simple as solving a Rubik's Cube where each side is a solid color. Rather, every website is unique, perhaps similar to others, but still has it's own individual requirements, much the same way that I created a new requirement for what it meant for Jake to solve the puzzle.

Upon doing a little internet research, it seems that there are some 43,252,003,274,489,856,000 (that's forty-three quintillion) valid combinations for a Rubik's Cube. When solving one for the traditional pattern, there is a well-established method to do so. However, when trying to solve for a custom design, most, if not all of that goes out the window. You still twist and turn but the algorithms have to be all new.

The thing about websites is that you don't just twist 'em and turn 'em until you feel like stopping and saying "Solved!" You have a goal in mind. Sometimes it takes a lot of work to get it figured out exactly what that goal is. Then you twist and turn until what you have matches that goal. It's a complex process because no two solutions are the same.

Here are some practical takeaways to keep in mind:

• Your customer, no matter what they say, has a very specific result in mind for you building their website.
• It is worth every minute to take the time up front to do design and business analysis.
• Changes made once development (twisting and turning) has begun is going to affect the deadline and is likely going to mean that some things are going to have to be done over.
• Testers are happy to look at your design before development begins and look to see if the corners match up the way they should.

The next time someone says to you the words "simple website" or "simple change", hand them two Rubik's Cubes that have been thoroughly discombobulated and tell them to change one of them to match the other.

Splitting Definitions

There are two words that we use interchangeably and even the dictionary considers them synonyms but I'd like to challenge us to be more judicious about when we use the word "normal" and when we use the word "average." For both words when we say that x is normal or average we're trying to convey a baseline against which to judge y. However normal and average imply completely different, I might argue opposite, methods of establishing the baseline.

Normal establishes the baseline through a rule. It's objective. Anything that doesn't follow the rule is abnormal.

Average establishes the baseline based on the collection of results. It's subjective. The baseline changes as the results change. Result x could be above or below average but it becomes part of the average when evaluating result y. If we wish to exclude x from the average then we're establishing a rule.

When it comes to software, functionality is generally normal and usage is average. In most cases we define [set rules] about how the software is supposed to work but we never know exactly who will be using it or how. It is quite impossible to set a rule as to who will be using the system. Instead we observe and look for trends and patterns. Be careful though because there is no such thing as an average user and when we create rules based on some composite, mythical person, we are sure to disenfranchise real people.

Normal = Objective. Average = Subjective.

Fast, Good, Cheap, and _______

The Triple Constraint or Project Management Triangle is a device that describes opposing variables in project management. The variation that I'm most familiar with has the three sides of the triangle representing: Fast, Good, and Cheap. The principle is that, when applied to a project, one variable must suffer at the expense of the other two, whichever one that is, or vice versa. For example, you can have a project run fast and deliver a good product but it won't be cheap.

Who says you have to sacrifice though? It's really not a "who" but a "what", which I recognize thanks to a recent post by Catherine Powell. (Our models differ but it's because of her that my brain got to thinking about this.) There's a fourth project component missing from the model and that's Scope. The fourth variable necessitates compromise but before talking about how Scope comes into play, let's review how the Project Management Triangle works. There is a variable for each side of the triangle A, B, and C and a fourth variable for the perimeter of the triangle D. The perimeter is fixed so that no matter what, A + B + C = D. If A increases, B and/or C must decrease. If A and B increase, C must decrease.

Why does the perimeter have to be fixed? Let's face it, most projects, if not all, have one thing that is 100% non-negotiable. In the Fast, Good, Cheap model, this is Scope. Without answering "what is this project about" you really don't have a project. Even if a project has more than one "non-negotiable," one will still trump the other.


As you may have recognized, the three sides of the triangle are not permanently designated Fast (Timeline), Good (Quality), and Cheap (Cost). Rather, the three sides are that which is not the paramount non-negotiable perimeter.

For Example
Timeline: The client needs a website to go live at the same time as a huge marketing campaign
Quality: The website must adhere to government regulations
Scope: The functionality of the website has to include everything specified
Cost: The expense of the project cannot go one penny over

Let's now apply these variables to the sides of the triangle. When a side of the triangle is benefited, it gets longer but it gets shorter when penalized.

Variable	Benefited	Penalized
Timeline	Decreases	Increases
Quality	Increases	Decreases
Scope	Increases	Decreases
Cost	Decreases	Increases

Using the Fast, Good, Cheap model for the three sides, let's say Scope is our fixed perimeter with a non-negotiable set of requirements. Let's say the company wants a bigger profit margin, which is in essence cutting the cost. If we want it to stay on time, the quality will suffer because of reduced testing. If we want it to maintain quality, the timeline will suffer because of less-skilled (i.e. cheaper) labor.

Under ideal circumstances, we'll have an equilateral triangle. This requires doing your homework up front. Figure out what your non-negotiable variable is and then set the remaining variables based on that. Doing this should minimize the need to make compromises enabling you to not have to change anything. If change is necessary and compromises are undesirable, the only way to change the perimeter is to change the contract either through a change order or a completely new contract.

Technical Documentation as Reference Material

In my line of work, I have been asked many times over the years to produce test scripts so that the client can "test" and make sure that the system is working as it's supposed to. Another way to put this is to document a complex, technical process so that someone with no experience in the field can do it. For some reason, I thought the testing field was uniquely privileged with these requests but that's not true. Similarly purposed documents are commonplace across disciplines whether it's requirements gathering or system deployment.

While the actual function may vary the fallacy in these documents is uniform. If the purpose of the document was simply to provide information to skilled people, there'd be no problem. However, the specific, implicit purpose of these documents is more often than not for unskilled people. A document is no replacement for skill or training because a document is limited whereas the realm of possibilities is infinite. Without skill, you'll be swallowed by infinity faster than the fish swallowed Jonah.

So why do we keep doing this?

Because it's an industry practice?
This isn't elementary school where we do things just because it's popular. We should foster practices that produce the best results.

Because the client asked for it?
We're not just code monkeys pumping out a website, we're consultants. It's our duty to the client to educate them on why technical processes should be executed by people with skills in those processes. The truth of the matter is that by doing so, we help to insulate themselves from disaster.

Because the client offered to pay us a lot of money for it?
Do I even need to say that this would be unethical? I hope this is never a factor. Yes, the client is paying us but with that we have an obligation to better the client not just give them what they want because of it.

Skilled Work for Skilled People
The most important thing that we need to take to heart is, as I said before, technical processes should be executed by people with skills in those processes otherwise the exposure to risk becomes extraordinary.

• Why risk having a site that isn't designed to do what it needs to? (BA)
• Why risk having a site that can't do what it's designed to do? (Development)
• Why risk having a site that doesn't do what it's designed to do? (Testing)
• Why risk having a site that isn't up when it needs to be? (Deployment)

References, Not Instructions
With that in mind, I think we ought to shift our paradigm about how we think about technical documents. They're not instructions, they're references. They guide a familiar process for someone that lacks specific knowledge for a given situation. When necessary, training should be offered to fully realize the necessary knowledge transfer. The training though is not to impart a skill, such as coding in PHP, but to apply an existing skill to a situation, such as coding a widget within the existing framework and dependencies.

Thoughts on Effective Project Management

Effective project management and execution has many components. To name a few that comes to mind:

• Planning
• Communication
• Cooperation

Projects don't always go smoothly though and so we compensate with:

• Process
• Documentation
• Incentives (or bribery)

Don't get me wrong, process, documentation, and incentives are not bad things but they're not guarantees for great projects. Just because you have process doesn't mean your project will be executed well. Just because you have documentation doesn't mean the project will be universally perfectly understood. Just because you have incentives does not mean your team will be motivated.

When the project struggles, don't panic and don't think that there's going to be a miracle cure. So what should you do? Breathe. Relax. Rather than jumping to a change in the model, figure out first if the model is being effectively executed. Sometimes all it takes is some individual coaching or team training.

Think for a second about treating a medical ailment:
Symptoms: Excruciating pain, being unable to walk or stand
Solution: Prescribe heavy medications, such as Oxycodone. If you can't feel the pain, then what does it matter right? But if you only treat the symptoms and don't fix the problem, the symptoms will reoccur as soon as the drugs wear off.

Problem: The leg is broken
Solution: Set the let and/or perform surgery to bolt the bone back together. YES! We are out of pain and we're mobile again. But if you only fix the problem and don't eliminate the cause, then someone is sure to come along and break their leg--OR WORSE!

Cause: The rug is bunched up
Solution: Smooth out the rug. If the rug is prone to bunching, tack it down or figure out what causes it to get bunched up. Perhaps it's to close to a door that opens frequently. If tacking is not an option or it can't be moved further from the door, replace the rug with one that has a non-slip back or that is shorter.

I contend that most issues in project management and execution are like this. Simple causes that, when ignored, cause expensive problems and exhibit symptoms disconnected with the cause itself. Fixing the rug is a simple fix. It's not a change to the model, it's just taking the existing model and working the kinks out.

[Not] Everything Is Urgent!

When projects get down to the wire, sometimes certain people (you know who they are) become prone to throwing out the rules for determining defect priority. As I previously wrote in Prioritizing Defect Reports, there are four factors that I consider when setting priority: Severity, Exposure, Business Need, and Timeframe. Unfortunately, Timeframe becomes a stumbling block when they fall prey to the terminal thought, "The deadline is right around the corner and all of these issues need to be done, therefore they are all Urgent!"

I call this a "terminal" thought because it leads to a disastrous method of project management: panic. Panic management occurs when organization goes out the window; and that's exactly what happens when all issues are prioritized the same. The priority indicator loses its value. Even when time is running short and all of the issues are crucial to launch, issues varying levels of priority and some need to be done before others. And what happens when nothing has any priority? Developers decided themselves which issues to do and when.

When we get to crunch time, I think it's appropriate to not only redefine the spans of time for the Timeframe factor but redefine the factor. Instead of thinking about a Timeframe, think about a Sequence:

• Urgent: Drop everything and work on this
• High: Complete before working on any lower priority issues
• Normal and Low: After confirming with the project manager that there is nothing more important that needs to be done, concentrate on the Normal priority issues first but may incorporate Low priority issues if there's an efficiency advantage. Low priority issues are completed last.

By maintaining your system of priorities, you'll help keep your team focused and everyone will have a clearer vision of the outstanding risk in meeting the deadline.