On Time and On Budget?
Chris Petersen
Do-er of the Difficult, Wizard of Why Not, and Certified IT Curmudgeon
Like a lot of my posts lately, this is more of a reaction post. In this case, it was a ton of memories colliding with this article (posted on Bluesky by the awesome Andi Mann ):
There are a lot of good things about the article, and in general, I agree with the recommendations. There are a few areas where I might prefer something a little different or perhaps a different spin on those recommendations.
On Time and On Budget?
As the movie Speed says, "Pop quiz, hotshot!" Which of the following, theoretical projects came in "on budget and on time?"
Or perhaps:
Astute readers will probably reply "Duh! Both!", and they're right, of course. That's why they're astute!
But, are those two project trajectories equally beneficial to the organization and the team(s) involved? Likely, not.
Software Development Life Cycle?
It may be wishful thinking or projection, but Project A seems like what we might hope for from a more Agile style of development work. The expenditures are relatively constant (when measured monthly), and the team(s) might even be delivering value, getting feedback, and pivoting, when necessary, throughout the project timeline.
领英推荐
Project B, which could be entirely necessary because of external constraints, ends with a "death march". It may not deploy before the end. It may not gather feedback as it goes. It may not pivot, and it may leave the development team(s) burned out and unable to cope with the kinds of "day 2" issues that often crop up after a "big-bang go-live".
I'd love to live in a world where Project B never happens, but there are just too many reasons why it can and sometimes must. External dependencies abound, and constraints are more than just a theory. Adopting, adapting, and continually refining Agile practices can be a positive force not just for the software developers and their customers but even for the finance folks.
Lead vs. Lag Measures?
Long and long ago, I read the book "The 4 Disciplines of Execution" (McChesney, Covey, and Huling - ISBN-10: 1982156988, ISBN-13: 978-1982156985). It crystallized my thinking about a lot of what was going on in my IT shop at the time.
If you measure both projects' "actuals" once at the end of the project, they may appear to be identical. They were each budgeted for $500K and 500 hours over 5 months, and they both spent $500K and 500 hours over 5 months. Yippee! But, that's a "lag" measure. You only know how things are going once it's too late to change. The project postmortem meetings might have been entirely different affairs for the Project A and Project B teams.
If each project was creating (and posting) its own "lead" measures (forward-looking statements/promises) and tracking what they did monthly, some theoretical boss might have gotten an eye-opener after only a month. That's one way to think about Agile iteration planning, execution, and assessment. The team is creating (and owning, we hope!) lead measures more often in the development process. They're posting those statements/promises somewhere and assessing whether they met them after each iteration.
In the end, Project A may have a party. Project B may get a whipping. If those teams communicate, you can bet that the Project B team will want to do things the other way when Project C comes around!
If you buy into "4 Disciplines" a bit more, those "lead" measures would have been shared with the customers or maybe even publicly (for some value of public) on some kind of visible scoreboard. Heavens! That's sounding more and more Agile (or Agile-ish)!
Easy vs. Hard Metrics to Gather?
As much as I agree with the original post, it seems like it relies on a number of "easy" metrics that may slip into "lag" metrics if leaders aren't careful. Tracking how much time and money go into projects from shared resources and budgets is a perennial problem in many organizations. "Team XYZ only needs to spend a couple of hours on Project A, but it will take that many hours to set up everything in the project tracking system!"
This is one of the areas where I fall back on my mantra: bake it in! If those kinds of processes and metrics gathering are too hard or add too much overhead, folks just won't do them. We have to make the right things the easy things. In many cases, there are "better" tools that enable such an outcome, but sometimes, colored post-it notes on a white board can work wonders.
Regardless of the tools we use, we can't shy away from collecting and analyzing useful metrics just because they're harder to collect. We can't shy away from doing that work as often as it makes sense. As above, bake it in! Folks can argue all day about what is or is not an Agile practice, but building in those conversations around each iteration is still key to long-term success.
Conclusion
Yes! Congratulations! You brought both of your projects in on time and on budget! You anted up your table stakes! Now, it's time to show you can improve from there, because everyone wants to know their resources are being spent "wisely" and they're not afraid to raise the bar on what "wisely" means every quarter.