I giggle every time I hear someone say “what can be so hard about software pm”? Seriously, it is funny.
There is a reason 50% of all software projects fail. There are a zillion reasons, actually. Where does one start?
After four years of being in the thick of it, it is sooooooooooo refreshing to be back coding. PM was the least rewarding and most agrivating thing I have ever done professionally. I’d rather sell hot dogs by the lake. Shot me if I ever do PM work again.
“Estimation is mostly guesswork, but if you have done work before and have some idea of what you are doing, then the estimate should be reasonable.”
There is the real trouble. Most of the time the tasks that I have worked on have never been done before and no one knows exactly what goes into them. If the development was something that had been done before or a set of tasks that one of my developers had worked before then we would likely just use COTS Software (or quickly integrate it). If a company is writing any significant code that usually means they are cutting new ground technologically. New ground means difficult estimations and high volitility.
Back when I used Project more often, I would use auto-leveling to keep the project in order. I would only apply dependencies between tasks if there really was a dependency. The auto-leveling was even smart enough to put the big (and therefore more risky) tasks as early as possible for each team member.
The other feature I used often was the tracking gantt. Each day or few days, you can indicate what’s been done or partially done, and Project can let you know if you’re ahead or behind of your baseline and by how much. Every once in a while to keep things simple, you wipe the slate clean and eat the overages by declaring a new baseline. Hopefully you had enough of a slush fund of time at the end of the project.
I actually miss Project a bit. Those were great features. I can’t believe basically every single PM I’ve ever seen do that silly every-task-is-dependent-on-something waterfall silliness – it turns Project into nothing more than a pretty Gantt chart printing program, basically useless for actually managing a project.
Has anyone tried to print those funny Gantt charts in MS Project? My experience is what you see is not always what gets printed.
When I plan I want to be able to plan one to two years in advance. Is there a sensible software outthere that can help with this?
Lots of comments already, so forgive me if I repeat what others have already said.
MS Project is the tool, not the content. As I have read somewhere, “the problem lies between the chair and the keyboard”. MS Project does not enforce waterfall, its just the easiest style of plan to create in the tool
Napolean said “A plan is good until the battle is joined.” meaning change happens, and MS Project is good for impact analysis.
the truth about estimating and planning software development is somewhere between “estimate before and it is must be perfect” and “you can’t estimate s/w development”.
Here is the definition of ‘estimate’:
n. (-mt)
So remind people that ‘estimate’ means approximate, not exact. Overall, estimates for doing anything are generally more accurate if you have done the same type of work before. Given that s/w development is often to build something never created before, that makes it tough to find previous work to compare to. Enhancements to existing s/w is easier than new s/w, and a package implementation is even easier as the vendor can draw on its previous implementation experiences.
So, tools don’t replace thought and judgement, they just make it easier to implement them.
MS Project does not enforce waterfall, its just the easiest style of plan to create in the tool
And isn’t that why it’s a problem? Tools do shape how you approach the world. If all you have is a hammer, everything looks like a nail.
Jeff,
I hate MS Project too. If you want to track a project’s performance against time and budget, this approach here works much better: http://www.agilekiwi.com/agile_charts.htm
It’s compatible with both agile and traditional processes. Agilists will recognise it as a “burn chart” and traditionalists will recognise it as a EVM chart.
I once attended a project Management training.
I don’t remember all the details, but one thing that I will always remember is that
the GANTT chart is an OUTPUT, a RESULT.
You don’t do real project management by writing in the GANTT view.
You work on the WBS (Workload Breakdown Structure) - that is the “list” of phases/items/tasks on the left end, you check the critical path, you plan in the resources, etc etc…
then the GANTT comes out for itself. You don’t need to actually work with it.
Most projects we see these days are done crap and look like waterfalls just because thet HAVE to be there (i.e. someone REQUESTED that a GANTT be there) but nobody actually knows both the tool and the methodology…
Project is horrible for several reasons, but its greatest flaw is that it assumes a static project structure. The documentation may not do that, but the UI sure as hell does.
You can create a starting plan easily and make it all pretty and straightforward. But then you have to enter actuals. The requirements change halfway through the project, and you have to add a whole section, and the Gantt chart blows up. You end with a project manager who spends a significant amount of time each day wrestling with Project. And they didn’t have enough hours in a day to actually do management, to begin with.
Those who don’t understand why software project planning is so hard are missing a crucial point. If you are developing in a well-known environment, using known tools and addressing well-characterized problem, you can make a good project plan. Unfortunately 90+% of software development projects involve complex undocumented environments, tools you’ve never worked with before, new and unstable technologies, and requirements that change daily. The only way to deal with that is to pad the hell out of the schedule, and even then something will screw you up.
This is one of the most interesting discussions I have seen in a long time. I am in the field of web-based PM software, so I can relate to both disciplines: PM tools and SW development.
From my experience and what I have heard from clients, I think there are 2 major issues when it comes to using MSP in Software projects:
1). Project Managers tend to go to granular - meaning they will try to micro-manage every aspect of a goal and end up with gazillions of tasks that suddenly get a life of their own and all need to be tracked and managed.
2). Updating plans with “actuals” quickly leads to situations where MSP will try to reschedule everything according to dependencies.
Thoughts about 1): When you plan a developers time, you should provide for more than ONE deliverable for any given time frame. I am talking about personal experience. Sometimes you just get stuck when trying to solve a problem, and you simply need a break from the mental dead-lock. You move over to a different problem and once that one is solved, your brain is ready to solve the first.
Thoughts about 2): Sometimes we have tasks that need a final phone call or a signoff before you can call them 100% complete. These final activities may be delayed because of absense, vacation, etc. - but they don’t really affect the schedule. The judgement of what affects the schedule can only be done by the PM not by MSP.
At my company, we are currently discussing the develoment of a web-based add-on to MSP for the purpose of tracking progress, sub-dividing tasks into deliverables, and providing some collaboration features such as document management and a message board. I don’t want to hijack this discussion in any way, but if you are interested in discussing this further, please email me at info@softalot.com and we can setup a seperate list (on yahoo egroups or what have you).
This is a very good discussion. The problem is not the tool although it does have it’s distinct weaknesses (who thought up single-level undo, anyway???). I have used Project for many years and actually have the (gasp) Orange Belt certification and (bigger gasp) my PMP. Project doesn’t force a waterfall - its just a natural way some projects get put together.
Project is a planning and communicatio tool and its use must be adapted to the specific project. We have projects that have lots of unknowns and I try hard to stress to people that when it comes to durations, dates, etc. we need estimates in order to forecase what will happen but its the project manager’s job to INSURE stakeholders understand where the uncertaintities are and what the range of possibilities are. That old phrase “based on what we know right now” must be heard loud and clear! PMI states in the PMBOK (please don’t stop reading at the appearance of this acronym) that the project is “progressively elaborated” the fancy way of saying "things change, there are unknowns that won’t come to light until later, etc. " It’s how that’s managed that should be the focus.
Finally, for anyone struggling to use MS Project, I highly recommend the book Dynamic Scheduling with Microsoft Office Project 2003 by Eric Uyttewaal. It is awesome and taks a lot of the mysteriousness out of the tool. It’s a good reference book too.
Good luck to all!
(Thanks to John Rusk for the link to the Agile chart!)
One more book recommendation - Agile Estimating and Planning by Mike Cohn. Eye opener and a fun read.
Here’s a giant thread on Edward Tufte’s site offering alternatives to Gantt:
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=000076topic_id=1topic=Ask%20E%2eT%2e
Scroll down 2-3 screens to see his version.
Ah MS-Project… I have a love/hate relationship with it. I have been using it since the earliest version to manage IT development projects and it has certainly given me cause to detest the day I ever heard of it. But every time I try and manage a project without it I kinda miss it, and I always end up coming back. Over the years I have learnt some basic lessons that are simply non-obvious from the tool or the documentation:
Always start off with a new Calendar for the project before you do anything else
Always assign each person their own calendar based on the (new) project calendar
Steps 1 2 ensure you can book Project non-working days (like Christmas) globally and give personnel their own non-working days in their own calendar.
Accordingly, NEVER try and use start/end dates, or adjust project durations or effort to try and cater for personnel being on holiday.
Then enter your tasks.
Then enter expected Work
NEVER add a dependancy if it not a REAL dependancy- you will soon tie yourself up in knots and for anything other than a small project, as soon as you start entering actuals the scheduling constaints YOU have imposed will kill you. You will then give up.
Then add resources to the tasks- Never use real names until you have firmed the plan up.
Frequently level the resources.
Worth saying again, FREQUENTLY level the resources.
Treat your first completed plan, before entering actuals, as nothing more than an outline planning and forecasting tool. Good for showing the CEO and the client when you kind of think their project will deliver. Reinforce the view this is a forecasting view only.
If you are lucky you might not need to use Project after that and the CEO and the client will trust you know what you are doing and let you get on with it. However, some clients (and CEOs) like to see the plan tracked. So regularly update the estimated completion, but judge it yourself- Don’t use the estimates to complete that the developers tell you. They will mostly always be wildly wrong.
After every session updating the relevant %age completes, use the Tools-Track Project-Update Project to set every uncompleted task to start after today. Then LEVEL THE PROJECT again.
Treat the revised delivery dates after all this as approximate delivery dates.
One of the problems is that Project tries to be all things to all people. I’ve been using it for years and I still haven’t got a clue about what a lot of it does. Find what works for you and work on it until you understand what is happening. DON’T try and get to clever, it will kill you every time!
I too have developed a love/hate, but very intimate relationship with MS Project. And like any intimate relationship, it has gotten ugly at times! I’ve certainly uncovered many of its flaws - it’s just too inflexible and completely ignores my needs! And it’s brought out the worst of my flaws at times too.
But, I’ve taken a step back, weighed the good with the bad, and decided that it’s worth living with. But, like any intimate relationship that makes it to this point, you get around to getting some counseling.
And for that, I highly recommend a book by Eric Uyttewaal alled “Dynamic Scheduling with Microsoft Office Project 2003”. All the good points summarized in many posts here are in there along with wonderful step-by-step, option-by-option instructions for building and maintaining a dynamic - meaning one which changes, moves and flows with your project - schedule that you can live with.
How to create a Microsoft Project plan fo a two day training session for people from different countries. Document everything including preparation, presenter issues, participant issues, accomodations and facilities in the plan. Help I do not know how to do these.
my project template includes four standard “bars”:
This way, client can easily save 35% of time cost upfront.
As of kitchen analogy, kitchen remodeling does not have any of these four “bars”.
Micosoft Project doesn’t support iterative protyping lifecycle. Therefore, you have to amend the project plan from time to time to reflect the reality. The thing is: you can always change your tasks but you can never bring yesterday back. Microsoft Project was designed like a calendar!
“It can be art in some sense of the word, because programmers do put themselves into the code, but it comes down to if it works or not.”
Whether software works or not is usually refered to as “meets its functional requirements”. What is about non-functional requirements that all add up to the software quality?
Why is software not like kitchen remodeling?
Well, it could be. When you remodel your kitchen, do you know exactly what questions will come up (“how much draw does the vent hood need?”, exactly what decisions you’ll need to make (“would you rather pay $X more or wait Y weeks for replacement material?”, and what unexpected facts will be uncovered (“I thought it was an 8” duct and I had no idea about the dry rot under the floor").
Is it acceptable to get the kitchen 80% done, then have the homeowner come in and say, “Now that I see how the frameless cupboards look with that style of door, I’d really rather have the kitchen island redone.”?
Or after the job is ALL complete and you just have the last guy mopping some dirt off the floor, “Those tiles clash with the cabinet color, I want the tiles ripped and the cabinets retextured with a metallic finish.”? Or even, “All the walls need to be moved out 3 feet.”? Does that ever happen? No, it rarely or never does, because there are tough guys with power tools in their hands explaining to you why that’s a bad idea. And the homeowner runs into a hard, pragmatic wall known as NO MORE MONEY.