It’s been some time since I’ve had a clear path forward. From March 2017 until the end of August I’ve been working in my first Government position but only in an Acting capacity. The role has been interesting, having a team and in particular not having a project of my own. It has been a big learning experience, working for others rather than a project, offering where I could, some of my insights and prior experience to help. Some have been really appreciative, others not so much. Part of me feels I failed somewhat, for not creating a noticeable legacy. Another part of me feels I set things up so I could transition into my new role, overall I’m still not clear how I’m leaving that position.
My new job is excitedly the best role I’ve ever had, the potential is huge. I’m truly fortunate, I get to step back into the project world, working under an experienced highly accomplished project manager, now program manager, it’s my first project manager role in a truly agile delivery, and needless to say, I’m super pumped.
How can I say we are truly agile? Since mid-June, I have been on the job market, knowing the acting role would come to an end and not knowing that transitioning across to a project management role within Parks Victoria was possible, so I was all over seek.com.au. I was, of course, wrong and am indebted to Tim Tunbridge, Neale Tayler and Jen Rebeiro for making it happen. However, I digress, through the process of hunting for a job and discovering yet again “agile” is a hot topic, but still realising from an I.T. project management perspective mostly/largely misunderstood. A number of companies and jobs have talked to an “agile” environment, but probing a little deeper, discovering a traditional culture still prevails when it comes to projects.
In tech projects, a traditional approach would be referred to as a “waterfall” method, Prince2 and PMBOK are renowned methods in this type of delivery. Basically, waterfall lays out the work of a project sequentially(mostly), wherein; scope, time and money are fixed, but consequentially quality is variable. Agile is by-enlarge seen as the way projects should be operated, but when you start to get a feel for whether or not scope is variable, as would be the case in a truly agile project, companies, supervisors, program managers get highly uncomfortable.
Part of me understands that as project delivery goes, you must inform the business on what you will do, but there is a distinction that needs to be made here. Ideally a team would talk about requirements with an asterisk next to it, something along the lines of “we are not able to predict the future, however, from our analysis we believe addressing these organisational problems will return value to the business and we believe we can get X amount of work done in X amount of time. However, as we progress we will learn more and re-assess what we have delivered against our initial thinking and how much we have spent. From here we can make an informed decision on how we progress and even whether the project is still viable.
During my formal education(albeit a one week course, I’m an expert now!!!) on agile project management (DSDM), I was blown away by the concept that during a project, at key releases/milestones, the project control board, would actual re-assess whether it was worth continuing. This can often, at least at first, seem like a negative thing, but it ties back to Pareto’s 80/20 principle. With functional releases of a project you will realise benefits along the lifecycle of the project, but there very well could be a point wherein 80% of the benefits are realised and the remaining 20% is likely to have less of an impact. At this point, it’s potentially worth considering if that money required to deliver the remaining 20% is worth it, or perhaps better utilised re-investing into anther project that might have a greater impact with the same money.
Coming back to my earlier point. We are in an agile world now, wherein scope is variable, time is fixed, cost is fixed and quality is fixed. Other organisations and projects are possibly impeding their success before even beginning by fixing every aspect of a project. Lately, I’ve thought about it like quadratic equations, solving for X, while all your other elements are unknown
Even though based on the elements of the equation, we can assess what X is worth relative to the other we don’t come away with a distinct value. You could say the quality of our answer is compromised as it is dependent on others. A project, I believe must have distinct benefits, independent of others.
I’m not naive to think there will not be challenges ahead, however, at least I know that there is hope to deliver something great without compromising quality. I.T. has an extraordinary poor delivery record, (RE: Standish report “CHOAS), some 16% of all IT projects deliver, all the others fail in some manner. I’m hoping to work hard and diligently to be in that 16%.