Promote My Site

Believe it or not, building software is not like building a bridge. An engineer can pretty much predict how many tons of steel it will take, how much labor, how long depending upon weather, etc. It’s a science. It’s predictable and repeatable.

Software, not so much. Yes, we can build predictable and repeatable processes, but development is more art than science. The only absolute is that the further out in the future you look, the more unfocused your vision becomes.

Most software development projects play a game of “gotcha” between the business and development sides. The business stuffs as many requirements and as little funding into the project as they can, and the developers try to narrowly interpret the requirements to meet their own goals. It usually doesn’t work out so well — software is delivered that technically meets the requirements, but it doesn’t do what the user needs.

Longer projects insert even more uncertainty into the process. When you’re taking large leaps, it’s hard to see where you’re going to land.

I’ve been running software development projects for the last 20 years, but I’m still surprised at how many experienced people just don’t get this concept. 18 months ago I flew across the country to attend a five day meeting on behalf of a client to evaluate the prospects for a huge software implementation being undertaken by a Global 1000 company. This project would involve hundreds of people, millions of dollars, and every line of business. And by the way, it’s a mission critical function for the company.

The meeting started off well enough. They had built a near consensus among all of the business groups that they needed to do the project, and they laid out a schedule starting with a set of “meta-meetings” that would refine the process that would be used to perform the implementation. They had roughly set out 6 months of requirements gathering and analysis, and had a vague idea that the development of customizations would be another 6 months, so the project would take a year.

The last day, a senior VP from the technical side gave his presentation. He obviously had not attended any of the earlier meetings. He laid out a detailed project plan for development of the customizations that would take place in parallel with the requirements analysis (overlapping development with requirements by 4 months). If they coded like crazy, they could have things ready for testing one month before the go-live date that the CEO seemed to think was a good idea. Mr. Senior VP really wanted to impress the CEO, so he wasn’t about to deliver a message that the schedule was outside of what the CEO was thinking.

I was absolutely flabbergasted. It wasn’t my job to stand up and call him a blithering idiot, but it was by far the greatest display of sheer stupidity I have ever seen from someone that calls themselves a developer. I so badly wanted to shout out “How can you possibly predict your development times when you don’t even know what the requirements are?”

Instead, I flew home, called my client, and said “This project is DOA.” 18 months later they’ve missed their first go-live by 6 months, the second by 3 months, and all indications are that they’re going to force a go-live a year late with a system that in all probability won’t work. By the way, the resource load is double what they thought it would be, so they’re 400% over the predicted budget.

Most projects suffer from a Catch-22. They really run on politics, not engineering. You can’t get an open ended project funded — the CEO will want to know that you’re going to spend $X to get $Y benefit before you can start. So you have to make a wild guess at what you’ll need to get the job done, and then hope that things go well. Unfortunately, hope is not a strategy.

Imagine sitting down with a builder and saying “I’d like to build a house.” He answers, “I can build a house for $100,000 in 6 months.” You answer “Great!” and then draw up the plans for the house you’re going to build. The catch is that Biltmore House is also a house, but it’s going to take more than $100K and 6 months to build. Holding a developer to a schedule like that makes about as much sense.

Smart developers know that they best they can do is predict ranges, and then modify their ranges as the dates approach. Ideally, you get the funding to do the requirements phase before you even talk about ranges. Whenever my upper management wanted to jump into a large project, my answer was always that we’d need X months to put together requirements and estimates. I was usually able to get away with that, because what most developers don’t understand is that the business people just want reliable answers, not pie in the sky.

The key is to constantly evaluate where you are. When we started our development project for Promote My Site the end vision was very different from what it is today. I think our vision has gotten better — the product will be much better, but it is also a lot less complex because we’ve been able to get rid of things that we don’t really need. We don’t have a cast of thousands working on this, but the team is big enough that it’s complex.

We recently decided to try for a stretch goal of a go-live in a window that would fit with some other things we were doing. We didn’t commit to a certain date, we just said we’d like to be able to go live on Month X, and a month before that we’d have a better idea of how it would be going. The planning side (stuff like burn rates) is well taken care of — we’ve got lots of runway there. The benefit of flexible goals is that you can bring your delivery dates in if your team is functioning well.

We had initially thought of outsourcing the development of this entire project. In retrospect, that would have been a disaster. We’ve had so many iterative changes that it would have been impossible to pull it off when everyone isn’t on the same team.

I can predict what my team will get done today with near certainty. It’s not that often that a disaster jumps up and destroys that schedule. The prediction for this week is still pretty clear, and you’ve always got the weekend to make up for slips. And if one team member hits something, the chances are that others can help out.

A month out is a lot tougher — if there’s a 1% chance that you’re going to hit a snag in a given day, then there’s a 20% chance you’ll hit a snag in 20 days. It’s all just a matter of how big the snag is. 3 months out is still very doable, but you have to really know your team and your subject area. If you’re breaking new ground, the best you can do over 3 months is say it’s a 3-4 month project.

So consider the wisdom of committing to a specific date for the end of a year long project, before you even know the scope. And frankly, I’ve never known a developer that hasn’t had to deal with that kind of project.

There’s a much better way to do it. Plan small, iterate, pay close attention all the time, and be reasonable. So far, the Promote My Site project has been pretty fun and I think we’re going to do a good job of hitting our goals.

When you were learning to drive, did your dad ever tell you to “brake early” or “shorten your sails before you dock?” Man, I just wanted the GO pedal and loud rock. I think your first startup is like that as well. Quit your job, hock your house, cancel your healthcare, work 1000 hours a week, and spend your money before your IPO. Then you run out of money, layoff everyone, and go back to work at your old job, slightly embarrassed at what a yerk you must look. But, oh, my, a little pause at critical points can really avoid a lot of that.

How can you pause and end up going faster?

Well, most people have a natural work cadence. And, like runners, at some point they have to stop and recover. That is a perfect time to have the management, or technical, or sales team down their work tools and do a review. Sometimes all you come up with is a buncha people jumping up and down and yelling GO! GO! GO! And that is fine.

But sometimes you get an “emperors new clothes” moment. And that, my friends, is the most valuable thing in the world. Because you just found out as early as possible that somthing is wrong. And the only time you can fix a problem is before you get wheels up at the end of the runway.

QED, the best time to have these pauses is in the beginning of the project, when everyone is freshest. There is a bit less group-think lockin. People are less invested in what they’ve been doing and are more willing to consider and propose changes.

Also, since money is always important, there are two times you spend the most money on non-payroll items: start and pre-launch. Dude, if you can find a better way to launch you can save a LOT of cash on that last end. And if you figure out (like I did once) that you are $200K short on funds, then you have time to actually go find ‘em! (I did, but barely.)

I will give you a personal example for Promote-My-Site . Early this year we decided that we (management) would carefully examine the build/buy issue but not consider which to buy or how we’d build. We wanted to make a policy decision, not a tactical issue. It took a few days, but we decided on buy - even though the rest of our business runs on both “built” and “bought” stuff. Then we tabled the issue for three months as it wasn’t critical in our development plan, except that we could put more resources on developing Promote-My-Site product and less on infrastructure. We basically bought a month of runway.

Last month we (management again) took a look at the ‘buy’ stuff and decided that we needed to choose between “buy” and “free.” Now, keep in mind that we had allocated a bit of cash ($150K) to buy whatever we needed so this was really another policy decision. So we looked at our options and decided on Joomla. Cool stuff, but we were bone ignorant on it and had to plan on the implementation at a later date. And we could release $150K from our accounting reserves to do “other stuff.” Like build more runway.

Finally, last week, when our team finished the architecture to support this project, we got everyone into the room and my partner and I presented our reasoning to the technical team. We’re both ex-techies so our guys love to give us a hard time and really challenge us. And they did. At one point some guys wanted to scrap Joomla for PHP/Nuke (eek!) but it all worked around to a non-unanimous decision that Joomla was a good idea, and one guy volunteered to come up to speed on care and feeding. So, we got confirmation that we were heading down the runway and it all looked good, except….

Someone else pointed out that we’d forgotten to consider a link between Joomla and SalesForce.com (where we manage our other sales force) - oops. So I’d have lost my integrated financial reports, which would have hit me *hard* during launch while I was juggling two different sales patterns. I’d have been out of runway, except that we took 7 people off a critical path project, stood two other senior guys up in front of them, and *planned.* Plus we’d put project money away earlier so we can pay someone to come in and do that project for us.

Planning saves time. And more runway is better. And the only way you can get more runway is to start to build it early in your project.

It really does, so I am amazed that more people don’t do it.

I’m not talking about the futile and overly detailed planning that takes place in most corporations. You know the kind: 80 meetings to determine the best rollout schedule for a new version of Norton Antivirus. Or, god forbid, the hundreds of thousands of hours spent trying to figure how to implement the next version of SAP.

I’m not saying that big companies don’t need to spend that time to get something even half right, I’m just worried that even incidental contact with that kind of lunacy might stop people from doing the kind of planning they need to do to be successful and save time.

Let’s just assume for a minute that you do enough planning to be successful. Maybe you can even do it in your head for smaller stuff. For example: I’m going to pull together an affiliate site for selling sneakers and I’m going to contract with X to do the writing, gonna re-use WP template Y, and I’ll do my normal link-love/bait strategy. Cool, especially if it works.

But in 25 years of working with various levels of very smart and very experienced people I’ve never met anyone who can plan a relatively large project in their head very well.

Our ’small’ example above was to roll out a variation of something you’ve done before. But what if you were going to start a business selling consulting to people who wanted to have a web store to compliment their bricks and mortar store? If you don’t take the time to plan in advance you’re going to blow some sequence, or pass up a sales/marketing milestone unprepared, etc. There is just too much stuff to keep in your head.

And if your business requires a partner, or worse yet, minions, then planning becomes even more important. The only thing worse than forgetting to do something is to do the *wrong* thing. For example, forgetting a deadline to get in the yellow pages (yes, people still use those - we make a lot of money off our yellow pages ads, thank you very much) is much better than putting the wrong ad in for a year. Not only do you miss the business, but you spend precious precious money to do it. Ick.

So, what kind of planning do you need to do? That is the subject for a book, I suppose. And it varies depending on what you’re working on and who many times you’ve done something like it before. For my business partner and I, well, we’ve got a lot of experience, we’ve worked together for years, and he, at least, is pretty smart. So for minor projects (add a feature to do X) we sometimes can bat around an email and get it all worked out.

For lager projects, like Promote-My-Site , well, that has taken us a lot longer. We’ve had a dozen large planning sessions, several hundred emails, and have gone through at least a box of white board markers. Our output has been a set of large lists that i keep on my wall and draw on.

We’ll talk about re-planning later.

But why has this planning saved us time? Because we have been able to ensure that we deploy our resources on the critical path items and don’t build X before Y if you can’t *use* X before Y! And because we never hit a milestone without being prepared for it.

Seems simple, don’t it? But you have to do it, and you have to pay attention. And you’ll see, in later articles, why re-planning and humility are important too.

It was kinda a long airplane and car ride to one of our client sites and we were through all the re/work for presentation prep. We were even through with the ‘news and gossip’ bit where we dredged up the funny jokes and juicy tidbits about former co-workers and employees.

So we got all philosophical about our existing business and how this new venture (Promote-My-Site ) was going to be different. Obviously since we were funding it from our existing revenues the ‘clench’ factor wasn’t there. (Which, as a serial startup guy, is fine with me.) My business partner, as usual, made a lot of good observations about market placement, pricing, and competitive advantage. (He’s the smart one, which will be obvious to you too at some point!

And then we got to talking about the most precious commodity in any business.

Time.

Sometimes there seems to be too much - business model says that customers need to be walking through your (virtual) door every five minutes but they are only showing up every hour. But that is an illusion of too much time. It merely means that you spent too little time on marketing, or advertising, or analysis/design. And now you’re operating and invested and going back to fix your marketing will take too much time.

Everything takes time - especially if you’re a small company. And so you never have enough time. (Old Steve Wright joke: You can’t have everything, where would you put it?)

If you’re in a large company (and I have worked at a few!) then you should have plenty of time - there are minions and support services guys and frameworks to support stuff like payroll and HR. But you have to have meetings to decide what to do and how to coordinate it and then the overhead guys have their own velocity which might not match your schedule, so you fall behind….. The time crunch feel slower, but that is the difference between hitting an iceberg in an ocean liner and a telephone pole in a Ferrari. It’s an illusion. There is never enough time.

But you do learn some things over 25 years of working. Here is the list of ten things we’ve learned to make the most of the time we do have:

1. Planning
2. Runway
3. Early Savings
4. Terminate
5. Replan
6. Focus
7. Stackrank
8. Triority
9. People
10. Humility

I’ll do some articles on these because they’ve all been on my mind lately as we balance our current business needs with this new product/service (we’re still discussing that dichotomy) that is in pre-launch mode.

I’ll also talk a bit about who we are as individuals and as a company. I’m not sure that a combination of our background and how we think wouldn’t be more helpful in understanding what we’re doing than any marketing literature I could write.

Plus, maybe, it’ll save you some time.

Welcome to the public framework of a coming-soon venture around social networking.

Gee, not many of those around the internet these days, eh?

True, but we think we’ve got something useful that will be additive to your business and ours, so keep a watch on this space.

We are going to spend the next few months introducing ourselves to you and explaining why and how we go about starting new businesses. Our theory is that this will help you understand our product better when we launch it.

And, frankly, this spin-off off of our current “stuff” feels so different than the many previous startups we want to explore that a bit ourselves.

I think we’re aiming for a more humble version of Guy Kawasaki or Dan Dodge or Matt Cutts. Not that we’re actually more humble than they are. But we also want to introduce ourselves to our future customes so that people can have an idea of who we are and how we think. Unlike, say, Guy, this is not because we’re important people, it is because the owner/customer relationship needs something non-transactional associated with it.

If I think about Amazon (to pick a a favorite vendor) it occurs to me that the less I know about Bezos, the more I am willing to consider competitors. As a company Amazon has lost it’s “face” over the last few years. In some cases this has been a good thing - hasn’t Microsoft been less of a techie target since Ballmer took over? Even in the bricks and mortar world, a change in face is key - a well known local pizza place moved and lost their ‘front man.’ Business dropped 20% and took almost a year to come back.

See, this is why we got so interested in social networking in the first place. Not so we could ‘friend’ someone, but because it is such a great tool to aid your business. And we’ll talk about that, at length. Because while you can have a good SEO flame war about link-love versus traffic, and thin affiliates versus content, etc, etc - at the end it comes down to using the web to get leverage on people *bigger* than you by being *smarter* than they are.

But first I want to talk about time. Because in a small business (in my mind, anything smaller than $200M a year is small) you are always short of time, so I think about that a lot. And at some point in the last year I got into a discussion with a close friend about “time” and how important that is, so it’s been on my mind a lot more than usual recently, so I want to start with that.