I was wondering….would you be able to post an article about the Art of designing a good project plan. There are tons of books on using MS Project and tons of Books on PMP concepts (initialize, plan…etc), but a well constructed project plan on a real project is always different. Or expressed another way, in Learn to Program in Java books, there are always the “Hello World” type example but just because you have mastered those “Hello Worlds” doesn’t necessarily mean that you have a grasp of designing a large J2EE project for a unique company project or that you have even grasped the OO concept accurately. In that same vein, there are no books, no blogs, no websites, no YouTube vidoes, etc on the “art” of creating effective project plans for large software development efforts (that include everything from procuring software, hardware, setup, change management, etc).
I believe Melinda is really asking about a topic I call project design. It is part analysis, part planning, and part problem-solving. I am going to outline a few principles today that I think are important for project design, and in a later post will go into more detail on each of them.
A well designed project doesn’t need Microsoft Project.
I haven’t used Project in over two years, in spite of the fact that I have been managing a multi-million dollar program that spans five different systems at my employer. We just put our last release into production last weekend, and not once did I open MS Project to create or update a project plan. A lot of people write this off by saying that my project is “simple”. It’s not. There are lots of integrations, changes in multiple systems that depend on each other, and several different organizations involved. My plan, on the other hand, is simple, because I’ve designed my project in a way that makes planning simpler.
That said, I do have a Gantt chart, but I make it in Excel, and it really is nothing more than a release plan. It shows which features will ship when, and I use it every couple of months to talk about what we will build next with my business partner.
Focus on features, not phases
Separating projects into distinct phases like initiation, planning, design, construction, testing, implementation, etc makes the planning more difficult, and it increases the risk of the project. Rather than starting with a list of phases, as most PMBOK-trained PM’s do, start with the features list.
Group the features that are similar. I talked about this a few days ago in a post called competence pie. Then, prioritize the groups of features with your business partners. Which are easiest to build? Which features can’t be built until some other feature is built? Which one should be built first?
Build the “best” features first
Try to make a smart choice about the feature you will build first. You’re going to learn a lot in the first iteration, which means you’re going to have mistakes that need to be fixed. Pick a feature that has business value, but also will be a learning experience. Don’t pick the easiest one first, but don’t necessarily go for the toughest one either.
My reasoning for this is simple. Project teams need to gel, and they need to explore the problem space. I’m always amazed at how the productivity of a team increases after the first release and at how much better we understand the remaining work.
Further group the features by what can be delivered in about two months
Long releases suck the life and soul out of project teams and business partners. Short releases build energy for both, because you can see the product evolving rapidly.
Organize your features into sets that your project team can build out in two months or less. If some of the feature sets you identified earlier are too large, split them up. Those that are too small can be combined. Review this with your business partner to make sure you haven’t missed something – sometimes one feature can’t be shipped without the other.
Make a Gantt chart that is based on feature delivery
Take your prioritized list of features and build a Gantt chart. I use Excel for this. Each row is a release, and I list the feature groups in the first cell. Then I make a column for each month and start planning which feature groups go when. I use a color coding system to differentiate between firm dates and tentative dates. I usually don’t have firm dates outside of two or three months ahead.
Collaborate with your business partner
This sort of planning is not what our business partners are used to, although I’ve found they much prefer it to phase-based plans that don’t let them see the product until the very end. If they are used to phase-based planning, you’ve got to get them over the hump, so to speak, to embrace this approach. Develop this plan with them, involving them at every step, and they will support you.
Plan every day
Melinda, I can hear you objecting to this approach right now. “But that’s not a complete project plan,” you are probably saying, and you’re right. I haven’t planned every single task that needs to be done along the way. I don’t do that planning until we start an iteration. Then, the project team and I sit down and quickly list out everything we need to do. We don’t try to plan iterations before we’re ready to start them. I’ve found this to be very beneficial, because it allows me to take into account changes in the team structure, business environment, business needs, etc. along the way. I don’t have to worry about whether my plans will be changed by outside factors because I haven’t set them in stone yet.
Build up to parallel efforts
After a couple of releases, you’ll realize you could increase the pace by having two tracks going at once, offset by a month. This will double the pace and result in monthly deliveries instead of bi-monthly deliveries. If you thought the business was happy before, you should see how they respond to this acceleration.
Please don’t split team members between releases (i.e. no multi-project multi-tasking). Productivity will plummet if you do. To run in parallel, you will need another team.
Measure the past to predict the future
Your first couple of iterations are very important because they will have the most impact on your overall plan/strategy. They will either validate the time-boxed chunks of work as being achievable or force you to re-design the project once you have gotten a sense of the pace your team can achieve. Make sure you involve your business partner in any refactoring you do, because you will need her support.
Build hardware environments in parallel with software development
Sometimes a software project also comes with a hardware project. This might mean you can’t deliver anything to production until the hardware is in place. If that’s the case, run it in parallel, and try to keep your software development team from getting bogged down in the hardware project, especially the procurement process. Build your hardware environment in a similar fashion – don’t do it in phases, but do it by environment. Build test first, then stage (if you need one), then prod. Leverage the things you learn along the way, and don’t build the next environment until you’ve delivered some code to the one you just finished.
Be careful though – sometimes the logistics in hardware procurement is very painful and you might need a lot more time to get hardware than to build software. I recently completed a software project faster than our procurement office could acquire technology, and as a result we had to wait for the technology to ship for over a month. If this happens, use the situation and your business partner to put pressure on your procurement chain to hurry. It generally works – nobody likes to be reason a production release is delayed.
Melinda, this probably isn’t the answer you were looking for. I know I have a fundamentally different approach to planning than many PM’s, but my projects are considerably more flexible than other projects I’ve observed, and I don’t spend a lot of time updating a project plan that is way too detailed. At any rate, it works for me. Please let me know what you think.