One of the advantages of being retired and getting paid to not work is being able to participate in web conferences whenever you want (unless, of course, the timing interferes with a spur of the moment road-trip or vacation). Yesterday, I sat in on the Project Management Institute’s Organizational Agility conference. If you are a member of PMI (or a student of project management in general), you know that there is a lot of activity around Agile software development and how the profession of project management fits into the “Agile mindset”. What the conference helped me better understand is that an organization can adopt Agile software development practices without the organization itself becoming agile. Sort of a “when Agile isn’t” situation worthy of a future article.
But getting more to the point of carts, horses and hurricanes, one of the conference sessions covered scheduling Agile projects. The presenter discussed her impressive experience with Microsoft Project and how she used it to maintain hundreds for project schedules for her pharmaceutical company employer. I sympathized with her observation that by the time all of the schedule details were added to Project, the schedule was out of date.
A favorite experience of mine in project scheduling occurred several years back when I spent the better part of two days working with a contractor to put a detailed project schedule together using Microsoft Project Server. Trying to breakdown an Agile development project into 80-hour work packages was an exercise in futility and contrary to the Agile approach, but that’s the way the PMO wanted it done.
A “special” (and I don’t mean that in a good sense) feature of the schedule was the PMO requirement to break it down by project option year with each option year handled as a single parent (or summary) year-long task. Subtasks extending across contract option years would have completion dates on the last workday of the option year and then start up as a new task on the first day of the next option year (chopping the task in two). It would have been simpler to create a custom column for the contract year and take if from there, using Project’s reporting features to aggregate by contract year, if needed. But I suspected the purpose of the schedule was really to track contract billings and not so much the work of the project.
Fast-forward several years later: The contractor is long gone, most of the PMO staff that instituted the draconian scheduling requirements are gone, the successor contractor is still struggling to complete development, and the schedule that took so much effort to feed into Project is lost somewhere in the bitbucket of time. At least the contractor made some money and we became familiar with Project Server. But in the end, the effort contributed a big fat nothing to the project.
Don’t get me wrong – you do need some scheduling in your project. There are parts of the project that aren’t essentially Agile. For example, setting up hosting environments and completing tasks to verify the cybersecurity of a release definitely follow a schedule. But this kind of work is probably better suited as a checklist, making it more useful to the project team as a tool than as Gantt chart or network diagram to hang on a wall. The program maps I mentioned in an earlier article are also great for showing the major events and activities over a wide time period. Aside from expecting a new release every several months, the detail in a program map is probably all most of your stakeholders need.
The point is that detailed scheduling of a software development project – Agile or otherwise – is impossible unless you know exactly what the requirements are and they will never to change, for the duration of the project. Good luck with that – especially for large, complex systems where the stakeholders have differing views of what the system should be. Investing a lot of time developing a detailed software development project schedule is like putting the cart before the horse. Also, to add to this metaphor, it gives the stakeholders unrealistic expectations – the cart is going to get them to their destination on time – even if the horse can’t push the cart.
During the question and answer session after the presentation was over, a question came up about budgeting. If the idea is to use iterative scheduling, as the presenter proposed, how can you budget for a software development project if you don’t know the size (or scope) of the system? This was a great question that, despite what the moderator said, did not illicit a good answer from the presenter.
The answer is that you should have at least some idea of the size and scope of the solution scope before you begin – or even consider – developing a new system. As I described in my How to Build a Business Case article, you can develop a pretty good estimate of the funding needed to get that new system. It’s a bit easier for modernization projects because you have a legacy system you can use as a baseline for estimating.
But all this seems to get lost when I listen to Agile development discussions. I think it’s because the presenters are focusing on the acquisition phase of the life cycle and not the stuff that comes first – like deciding if the best move is to build a custom system rather than buying an off the shelf product. All that work seems to be a black box that’s done before launching Sprint Zero (if using SCRM) with funding magically appearing.
This leads to my next metaphor about hurricanes and estimates. Take a look at the map below showing the potential track of hurricane Florence. At 5:00 AM Monday morning, NOAA knew exactly where the hurricane was located. Notice the plots on the map showing the estimated location of the hurricane in the near future.
As we look father into the future, the area affected by the hurricane becomes wider because of the uncertainty of how the weather systems and other factors will affect the storm’s path. The map shows that at 2 AM Friday morning, the hurricane will make landfall near Wilmington, North Carolina. But there’s also a chance it could land near Hilton Head Island, or Virginia Beach.
At 2:00 AM on Wednesday, NOAA will know exactly where Florence will be and can update the map with new information. The “cone” will be smaller and we’ll have a better idea where the storm will come ashore. Also, we’ll know if Wilmington or Hilton should adjust their storm planning.
That’s similar to the way project scheduling and estimating works. When you get an estimated cost from the cost benefit analysis (covered in my How to Build a Business Case article), the estimate is risk based, meaning the “cone” you see on the NOAA map is built into the estimate. So when selecting an alternative, use the risk based estimated cost as the basis for your budget. That will put the horse before the cart and help fend-off those hurricanes.
In the meantime, to all my readers out there in the potential path of hurricane Florence, please heed those warnings and head for safety. Nothing is more important to a project than the health and safety of the people working on it.