This doesn't mean you can't be your usual, happy-go-lucky self! In fact, it's absolutely vital that you approach any project with a healthy 'yes we can' attitude. However, there is such a thing as being too cheerful or optimistic about the outlook of a project time line, and the consequences can be devastating.

In all things concerning long term goals (and this is especially true when making software) things are going to go wrong over time. Functional requirements are going to pop up that nobody expected (but are vital to the product), people are going to miss meetings (blowing the time line out of the water), some tasks are going to prove much harder to accomplish than anticipated (draining time and budget away from the project).

There are so many things that could possibly go wrong with a software project that there is no sense in attempting to outline them all here. While you can anticipate such unfortunate events and plan around them, I can promise you that despite your best efforts, you will still get blindsided before the project phase reaches the end. Often times, it just boils down to the needs of the client changing in mid-development.

Given that unforeseen circumstances are inevitable, you have a choice when building your project plan. You could choose to shrug and have confidence that your estimations are spot on and that you've considered everything; clients love low cost numbers when shopping for options! But be prepared for a very uncomfortable phone call if something goes wrong and you find yourself asking for more time and budget. You can just eat the cost too - which will protect your image - but your bottom line will suffer.

The alternative is to approach the estimated timetables with measured pessimism. Time line seem a little tight.. or too good to be true altogether? Here's the news: it IS! That's a promise. The sweet spot for how long things will actually take looks a lot like the edge of taking too long to get things done. You'll want to make a plan that leaves enough time where there's no way that you won't make deliver your promises. If you do that, you have a healthy shot at getting the project in on time and under budget.

When your time line is adjusted to account for the unknown, your client may be a little surly about the price tag but believe me: If you deliver the product you promised on time and under budget, you will become a hero in their minds. This is important if you're interested in their long term business. This is vital if you are to become somebody that they trust. This philosophy won't land you every sale that comes in the door, but this will land you the sales you want - and if you're successful, you'll probably get to keep them too.

Software is expensive because it is irrational and difficult to build. More than 70 years of mostly-failed software projects evidence this fact. Face it, and your chances for success will dramatically improve. Any client worth working with will accept this, any client who doesn't will pay through the nose when some snake-oil peddling, imprudent shop promises the world and delivers them only mud, budget woes, and unstable time lines. DON'T be that shop; the world has enough of them already. Over time, the world gets wise to who they are.

2. Embrace your inner pessimist... DEMONSTRATE YOUR ETERNAL OPTIMIST

The answer to every question the client asks, regarding possibilities should be 'yes.' After all, if you put your mind to it, you can accomplish anything. But the situation is a little more complex, right? The late, great President Kennedy knew that it was possible to fly to the moon and back, so he declared it and made it a national priority. But he also knew that to make the leap from dreams to reality, budget and time were required.

Just as this is true for any dream, it is true for software. Your team can do anything it puts its collective mind to, provided it has the necessary budget and time. Some goals are so lofty that it is nearly impossible to predict just how much time and budget it will take. Imagine if Lincoln made the same moon promise as Kennedy, but in 1864. Lincoln wouldn't have been wrong about his supposing that the trip could be made, but the world had much less in the way of tools - and will - to support the goal.

The moon mission might have been made within, say, 50 - 70 years of such an announcement if the nation (or world) had completely committed itself to space travel and the supporting technology in 1864. The fact that it took until 1969 to realize the goal didn't have as much to do with incapability as it did priority. Given the circumstances in the US in 1864, flight to the moon wasn't just an extremely challenging goal, it was also impractical given the difficulty and the cost. It was also much less important than preserving the Union (for instance), or a myriad of other outside priorities.

In some sense, this same analogy applies to your client's new website. Say your client wants to build a website to show off their portfolio and to promote their business. Your contact says that they sure would like it if the website had a little sea urchin in the corner that, when clicked, would jump around the page and generate fun facts about each portfolio piece. If you click it three times, I dunno, it calls your significant other at home and tells them you'll be late coming home for dinner. Or something crazy like that.

An appropriate response might be: "Yes... we can do that! It is difficult to say how long this would take, as we've never worked on something quite like that before. Would you like us to dig a little bit and try to get a sense of what the budget and time line would be to deliver something like this?" It is at this time that your client will give more serious thought to their pet feature – will it really be worth the cost at this point in time?If they're still serious, then buck up and get ready to research.

Barring goals that require time and resources in excess of a lifetime, you can do anything you set your mind to. Just don't ever commit to a goal you don't understand completely. You can assert the possibility (and your team's capability) to accomplish almost any request. You can commit to understanding the issues first (which will, again, require time and budget), then once you can say something intelligent about the time and budget involved, you can commit to the ultimate end goal, whatever it may be.

Yes is not a promise (unless you're not very careful with your words), Yes is a state of mind. When paired with realism and prudence, Yes can move mountains. Use it wisely, and it will take you everywhere. Use it poorly, it will ruin your reputation over time. Neglect to use it, and you'll invite doubts about your capability.


This one is old advice, and obvious, but it is also amazingly overlooked. I'll keep this point simple, because this point is simple! If you see a problem, complication, expense, or any adverse condition on the horizon... SAY SOMETHING! If taking preemptive action sounds like a pain in the rear (maybe you're busy with other stuff or just don't have the energy to pick up the phone), just wait until the problem you're anticipating manifests itself. Perhaps it will come in the form of contract renegotiation or a flurry of angry phone calls with your name on them. Or worse yet, losing a contract in mid-development.

Life stinks when preventable problems come to pass. Don't let this happen to you - be proactive and productive in the face of danger. Clients notice your actions and inactions in such events, too. Be sure to show them they're dealing with a Project Manager who is looking out for their interests.

4. PREDICT THE FUTURE INTELLIGENTLY (and count on your Devs!)

Putting together an estimation of work not yet performed is tantamount to predicting the future, and predicting the future is a tricky business. Everybody who has ever dipped their toe into the task of divining the future has (or will) probably be called a charlatan at some point in their lives. Palm readers, weather forecasters, market analysts - they all invariably get something major wrong from time-to-time (if not very often).

If people are so consistently horrible at this task (at least historically), then why is the demand for this service so high? People seem to have a strong desire to know the future, and for a lot of good reasons! The need is as old as documented history, and though the soothsayers wear different suits now, the principles are the same. People want to know if they're making the right moves - especially when something important (say... tens or hundreds of thousands of dollars) is on the line.

Your client is looking to you to predict the future! Terrible, I know, but if you stop and think about it, this is absolutely true. They need to know what they're going to get, and when they're going to get it, after shelling out thousands of hard-won dollars. And if you're wrong, it's your name that goes on the shame list.

But instead of counting on mysticism or a lot of dunderheads on the television, you have a way more reliable source with which to perform this miracle: you have a team of experts on your side. These experts know what it is to get their hands dirty; They know first-hand the pain and agony that can come when things rough on a project. Your development team knows where the (known) pitfalls are, what tasks promise to bring large amounts of risk, and in general, they have a better sense than anybody else you know when it comes to the time it takes to get things done.

It is with the above in mind that I advise you, dear reader, never to promise anything without at least consulting with your development team. Simple ideas may involve limitless complexity that you've never imagined, and crazy-sounding ideas may be possible with the flip of a switch. If anybody can tell you which is which, it's your developers. They're the only ones who have tried these crazy things; sometimes the experience is still fresh in their minds.

The best approach, in my opinion, is to gather up all of the functionality that the client is inquiring about, and bring that information to your development team. Give them a day or two to read through it and bring some estimations back to you on how long it would take to implement each piece of declared functionality. Chances are, you'll probably want to boost those figures you get back (unless you're dealing with a particularly experienced and cautious developer), but the baseline figures are as good as they're going to get. More than likely, they'll point out a few risks and points of insight that never even crossed your mind.

If you're getting a ton of ideas or cautions back from your team, you may wonder what good your work is. After all, if your dev team is coming up with all of these ideas you would have never thought of, then why are you here? Is this you? If you answered yes... GOOD! This means you're doing your job. Collecting as much understanding as you can about the situation your walking into, and then making a plan for dealing with that situation as well as possible, is exactly what you're paid to do.

You're not expected to be the leading expert in every detail of the project, just in the plan making. Making a good plan means getting the best, most complete information you can get before putting pen to paper. To get this information, one often does well to turn to experts. Leave your ego at the door and engage with your developers when their input is of value to the project at large (which, when it comes to dev work, is always)

Leaving your predictions to chance, hunches, feelings, etc is an almost certain recipe for failure, at least when compared with the predictions of those who do their homework. Turning to your developers to provide you with critical analysis on the important part (the development of the system) is absolutely mandatory homework for those who wish to gain an educated understanding of what is to come.

There are many other activities which must be performed as well to gain an accurate understanding of what lies ahead, but in my experience, communication with your team is as indispensable as requirements gathering. The more you know about what you're walking into, and the smarter you handle it, the more valuable you are to your client. And if you can predict the future, rest assured, your name will not soon be forgotten.


Thanks for the great advice! While large portions sound like they should be self-evident, somehow you end up making such stupid mistakes anyways – sometimes again and again. So I think this write-up is really helpful.

I myself am a freelance developer, so I'm kind of developer and project manager unified – but I thin most of the tips still apply.

Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <blockquote cite> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h1> <h2 id> <h3 id> <h4 id> <h5 id> <p> <br> <img src alt height width>
  • Lines and paragraphs break automatically.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.