≡ Menu
Pawel Brodzinski on Software Project Management

Why Slow Start in Project is Such a Great Idea

We’ve just started a new project. We are at the very beginning and we still don’t work under pressure of time. And that’s great. Such slow start is a chance. A chance to set things up as you would like them to see in ideal world.

We use this chance to:

• Choose and verify tools used during development. Continuous build, unit testing, static code analysis, coding standards – all this things which should be on place but so often there isn’t enough time or you have to throw everything away because of some emergency. And if you try to do it in already settled environment it’s such a painful and long process.

• Design properly. Have you been in a situation when you just do your wild-ass guesses (aka rough early estimates) and suddenly you have to start coding because you’re a month behind a schedule before even a contract was signed? It is said that testing is the first place where you (unwisely) cut schedules. Well, designing holds a strong second position.

• Find time to discuss requirements. Is all clear? Yes? Good. Write it down. Go at least one level deeper to get more details. Another time write it down. Now, get people read it and understand it. Are there any questions? Of course there are. Congratulations, you’ve just eliminated some issues which would appear later and would be way more painful.

• Adjust project management techniques. Ensure you gather all the data which will point how much you miss initial estimates. Set workflow for work items which won’t be a pain in the ass for developers. Think what people pointed as problems during last post mortem session – do you always find time to use this knowledge to improve your projects?

Basically all these things are just simple ways to avoid or limit technical debt. If you start slow it’s much easier to set them up properly which soon will return in terms of team general productivity. Of course that does mean additional work if you compare it to impossible-to-meet ideal world schedule where everyone produces best of breed results with highest possible performance.

The reality is that projects with technical debt starts producing visible results faster but they soon lost their advantage and over time are more costly. Starting a project slow gives you an excuse to do a good job in this area. You can need one for your bosses and you can need one for yourself.

in: project management, software design

10 comments… add one

  • Evgeny April 10, 2009, 2:53 pm

    If you read the book Slack by Tom DeMarco it would only seem reasonable to do so. And not just starting project slowly, but also having this slack buffer all along the way. It both helps reduce technical debt, and is just better risk management overall.

    If you havent read this book yet, I highly recommend it.

  • Pawel Brodzinski April 10, 2009, 3:09 pm

    It’s hard to keep slack all over the way when customer generates more pressure and deadlines become more tight.

    Another things are Parkinson’s law and student syndrome which basically tell you that work will fill all available time.

    Anyway if I had a chance to maintain a slack buffer all over the project I would go for it especially if I worked with great self-motivated team (I’m happy to work with one these at the moment). On the other hand I have no illusions that we’ll be able to keep that approach all the time – our customers will force us to change it.

    Thanks for book recommendation. I’ll read it for sure.

  • johnfmoore April 10, 2009, 5:03 pm

    Great post, Pawel. It is difficult to stay ahead of the technical debt, especially in the startup world that I live in.

    However, I like you key ideas, especially around investing in the right design and product management practices. These will provide your team with solid return and benefit you both short, and long, term.

    Keep up the great writing.


  • Pawel Brodzinski April 11, 2009, 1:59 am

    Staying ahead of technical debt is hard in startup world, but at least it’s usually you how make all decisions so it’s in your hand.

    It’s even harder to keep away from that when you work for bigger company and all your bosses don’t care and expect all projects ASAP, where ASAP means 2/3 of the most optimistic schedule you’ve ever made for the project. Then it becomes a war on two fronts: you have to deal with a client and with your management.

  • galleman April 11, 2009, 7:40 am

    Good recommendations. But wouldn’t it be better to perform these activities as part of the project. The Project Initiation process? Before existing the project initiation phase, the project is bound in some way, resources are estimated, and your “wild ass” guess is turned into some credible estimate of cost and schedule, with the statistical upper and lower confidence intervals.
    In many domains this is called the Performance Measurement Baseline. It’s the starting point for the project. One that undergoes change as the project proceeds.

  • Pawel Brodzinski April 11, 2009, 9:59 am


    Of course it would. Unfortunately there are few of us who can control our project management processes fully in terms of how many time we are given and which action we exercise. Our deadlines are often forced by a client or by senior management who doesn’t want to see you spending much time on planning but rather on programming.

    It may look different from VP perspective especially in established company where losing one of deals isn’t a tragedy. However it’s very common to see environment where project management and software development practises aren’t put in any order (in other words every team do what they want) and there’s high pressure from the top for kicking out project immediately. If you’re out of luck your salespeople doesn’t care much about your estimates and you end up with something impossible to do from the very beginning.

    Then a slow start is a chance which can and should be exploited.

  • galleman April 11, 2009, 2:13 pm

    I’m always puzzled by your comments. Could you provide some background as to why you cannot control the PM processes as the PM.
    I understand it happens, but I’m interested in the underlying cause.
    On our projects we are always behind schedule and over budget in some form. It’s just the nature of the business. But senior management has no illusions about that being the case, fully recognize this as the case and ask for our “get to green” plan every week. It doesn’t always happen, but there is fullr recoginition that we need one, and without the full engagement of the program and the management, we’re going to fail in a big public way.
    I’ve seen very bad behaviour in our domains, just courious as to why it is that way?

  • Pawel Brodzinski April 13, 2009, 2:53 am


    A few examples:

    1. You, as a PM, join organization where project management practices are already settled. No matter if you agree with them or not you have to follow, since even when they aren’t very good people got used to them and are reluctant to change. You can’t control how e.g. estimating works since you aren’t superior to people who are involved in the process.

    2. You join organization which works under constant emergency. Your efforts aimed at improving poor project management process are undercut by senior management since they expect you to fix the most serious problems in existing project first and then try to change the process. Unfortunately as far as you don’t change the process it’s hard to escape firefighting work. On the other hand organization isn’t healthy enough to be able to invest enough time and money to leave problems aside and start improvement work.

    3. You’re a VP responsible for project management and software development. The company is going through financial troubles so the firs goal is to balance costs and revenues. At the moment your team is already overbooked but there’s a chance to get a deal which can get you out of troubles. The bad thing is you can either try to engage the new deal as you’d do this in normal situation but at the expense of current projects or you can try to find some sort of “good enough” approach which won’t impact current project too much but won’t give full support for a new deal either. You do it because if you engage all people to a new deal and lost it the game is most likely over since you wouldn’t have a new project and have serious problems in old ones. It’s just risk mitigation.

    4. You’re a PM and you come up with reasonable and well-prepared schedule for the project. The response for the sales team is “Too long, they won’t buy it. Cut it in the half.” You can either agree, reject or go to your boss to help you. Either way you most likely end leading a project which is a death march from the very beginning.

    5. You are a program manager and start a new product in a company. You get your budget and product plans accepted. Somehow the project becomes very important for your VP and it gets a lot of buzz around the company. You start working under pressure since everyone starts expecting visible results soon. People are throw in to the team with no consultancy with you. Your plan to prepare tools first and then start development is cancelled and you’re forced to start working on “real product” instantly instead of wasting time on “unneeded prototypes.”

    I’ve been there. I was in the middle of each of above situations. Theoretically I should be able to model all project management and software development practices as I wished but the reality in this way or another forced me to compromise.

    Of course it’s often the problem of senior management but they play by the rules of market. As a plain PM I most likely don’t know financial situation of the company. Maybe some decisions were driven by a company overall condition? Who knows. I don’t blindly blame my VPs for decisions I don’t agree with.

    Anyway, coming back to the thread, in almost all these cases (except of 4 maybe) if you’re able to start slow you can fix many problems you face. Yes, it should be integrated with a project management process but it rarely is. Actually when you know environment you work in well enough you can sometimes expect some changes you’d like to avoid but unfortunately you don’t control them in any way.

    At the moment I don’t expect we’ll be able to maintain all practices we use now. As long as they work for us (since some are new for us I don’t expect all will be here in the long run) I’ll defend them, but when thing will go hot I have no illusions about keeping software development and project management processes ideal.

  • galleman April 13, 2009, 6:57 pm

    Maybe it’s a language disconnect. Your description appear to be environments are where you “can” control the PM processes, within the context of the problem. The processes may be suboptimal.
    Ron Jefferies once remined me – when I was complianing about a client not deploying XP properly – yes I have managed agile projects.
    “You need to get better clients.”

    1. Why would a person take a job as a project manager in such an environment useless that was the only job to be had?
    2. Same
    3. As VP you most certyaintly have control over the process and should adopt them to fit the financial situation.
    4. As the PM your need to cut in half also come with half the features. If not, look for work somewhere else, becasue the firm will not be around long.
    5. As the Pogram Manager you job is th emanage Project Managers. Having a credible plan inside the constarints of budget and time is always a problem. It’s a problem on our $800M software development program. Planning works.

    Ideal practices are of little use. Pragmatic practices are. Just a suggestion – look around in the literature for example of this – PMI Journal, IEEE Transactions on Engieering Management, of outlets to see your problems are common, but with different approaches.

    Also the code of PMI ethics has something to say about taking on work you know will fail.

    Again, just a suggestion, your milage may vary.

  • Pawel Brodzinski April 14, 2009, 1:36 pm


    My intention isn’t to dispute about words. I guess you more or less understand my point. Since English isn’t my native language we may have some disconnection here from time to time.

    For every complex problem, there is a solution that is simple, neat, and wrong.” – H. L. Mencken
    This one I’ve learned from you.

    If you need short retorts for each situation:

    1. I didn’t know how really things looked like. On the other hand I’m not the kind of people who walk away not even trying to change anything around.
    2. Same. Plus some friends worked there which adds a new perspective.
    3. As far as you’re safe talking about finances, yes. If you’re not the process is pretty long and takes a lot of compromises. In the long run I can say I was successful though.
    4. As a PM you not necessarily control what was promised to the client. You can reject to work that way but the same as in 1 and 2 applies.
    5. Credible plans work as long as your incompetent superiors start changing things as they feel in their guts and reject to discuss merits. Of course you can look for the other job…

    I guess we could go with that discussion pretty long, but i believe the real question is: if you find yourself in situation very far from ideal (each of examples works here) how long you try to change/improve things around and which compromises you accept before you leave.

    In this way or another I consider myself successful in fixing three of above cases, but it took way more time than I’d predicted, and I left in a couple of others and at least once it was more “first do than think” kind of situation but I don’t regret anyway.

    Yes, the world isn’t ideal and usually we try to do our best in given circumstances. Sometimes it does mean finding another company, sometimes dabbling in crap. How you act in specific situation depends much on our knowledge, experience and gut feelings, but that’s another discussion we carry out on your blog.

Leave a Comment