Why We Can Never Make Just One Change As A Project Manager
“This happens in part because agile adoption has been practitioner-led, leading teams to focus on themselves. Areas outside of their control, such as project planning and release management, still follow more traditional approaches, so Scrum adoption is limited to the development team.” David West, Water-Scrum-fall is the reality of agile, SD Times, Dec 2011.
We hear about it every day. Just eat this one berry-based product, and your health will never be better. Buy this mattress and sleep well, and your day will soar to new heights. Purchase this Project Management Tool, and you will never deliver a project late again.
I am a big advocate of doing a few things right. One technique is to take one thread of the project and focus on it, getting it to perform very well. This approach helps related processes firm up and start working well also.
This notion, that optimizing one thing can help improve others, needs some elaboration.
While this might be originally a focused project (e.g., let’s adopt Scrum), what we found and hence look for is how the change also supports and encourages change in other related processes (e.g., project management, costing, quality, release, etc.). In fact, what we often — almost always — find is that to make much progress at making that single process highly effective, we must adapt (often, fix) all those other processes that feed into it and that take their output from it.
The unifying notion is that by doing any one thing well, we have to inevitably do multiple things well. Picking that single process as the starting point requires the recognition that we will spend time on related processes, making them perform better also. The single dimension becomes the anchor, but it has to anchor those other processes to gain the expected advantage.
To Do One Particular Thing Well We Have To Do Multiple Things Well
I was the new chief of computer and network security. My job was to implement what seemed like some pretty simple security requirements (e.g., quarterly changing but random passwords, separation of secure workstations so someone can’t look over your shoulder when working, secure rooms with access lists, etc.). While as simple as these rules were, it was tough to get everyone to implement them. I found myself spending time helping folks simply manage their resources (find their workstations, find rooms that accommodate extra space needed for security, etc.). I noticed, however, a simple pattern. If the person running the department was well organized and knew what they had and where their equipment was and who was using it, then adding on security was just a detail.
For folks who had no clue where their security workstations were or who was going into their secure rooms, then adding security meant first needing to implement basic department and equipment management. We would find the worst setup possible — a line of secure workstations side by side and crammed into a small room (with a huge window behind them) and the demand “ok, how do I separate all of these?” The notion, for example, that we may have to juggle multiple rooms to meet the requirements was heretical (“why is security running our department!”).
When all was said and done, we got compliments (often quietly) for getting some departments to not only get their security right, but also for getting them to finally manage their resources (e.g., their offices were no longer a confusion of equipment and wires).
So if a project management tool is seen as being a silver bullet to fix the organization (e.g., Six Sigma, ALM, Agile, Scrum, CMMI, ITSM, TDP, PMO, Prince2, etc.) then the chances of it being truly successful are increased by recognizing and planning for improving related processes.
Have you noticed and planned for how making one change will often domino into multiple needed changes?
6 thoughts on “Why We Can Never Make Just One Change As A Project Manager”
Comments are closed.
More comments from around the web:
Andy Rozylowicz • If there is no support, no change will succeed; time to change jobs
Megan Gossett • Easier said than done in this economy, but I still hold out hope. I have been in multiple organizations where this has been an issue. We as PMs are the advocates and should work to push reuse and then rebuild if necessary.
Follow Andy
Andy Rozylowicz • I understand. It is really tough to go to work when you know you are doing a replay of “Thelma and Louise”.
More comments from around the web:
Megan Gossett • Sometimes those who don’t care to understand the current process, meaning leadership in most cases, push to reinvent the wheel. I agree with both Andy and Bruce, but the challenge comes when the needed support is not strong.
More comments from around the web:
In addition to looking at where your anchor process gets in inputs and sends its outputs, there should probably be an examination of the more human side of things ass well. Do you have buy-in from all the stake-holders? In the posted article, it sounds like the author (or his team) failed to get proper buy-in from all affected stake-holders. If everyone affected by a project doesn’t buy in, you’ll be making changes all over the GANTT chart, no matter what PM methodology you use. This could be a leading cause in scope creep.
Posted by Ian Kahn
Kahn,
The example in the article was a project “required” by a downward directed policy. So you are right, there was not much buy in.
I also agree that without buy-in we can expect “last minute” changes which really are not at all last minute but simply represent requirements we could have known about if we got everyone involved in what needed to be done.
Good point.
More comments from around the web:
Mark Larigan • As a project leader you need to be vigilent for the infamous “scope creep”. There is always pressure to add new targets and goals to a project, and it takes a strong leader to keep the team focused. Regardless of the methodology you employ to track your project, the key is to stay on track and defer multiple goals to a seperate project(s).
Bruce Benson • Mark,
Agreed. I do believe every project should plan for some “normal” scope creep, but the notion of staying focused and having an “outlet” to put additional scope is important.
In one large project, where previous projects like it suffered extreme scope creep, I simultaneously defined a second project that would follow our large project and serve as a technology refresh for that product. While it was normal to have a refresh product, what was different is I planned the two together. Since I had the refresh project defined, at least as to timing and resource reservations, then I had a “place’ to put all the new ideas and other scope creep that naturally occurs.
Since my refresh project was already defined then when I would promise the additional capabilities in the “next release” so as not to disrupt the current project, the customer (internal and external) could see concrete plans and approvals for their requirements. This made them less likely to insist they go into the current project (but not always!).
Thanks for the feedback!
Comments from around the web:
Andy Rozylowicz • Organizations have oth delivered succesfully and failed to deliver successfully for decades. I have rarely (never) seen the root cause of failure be tool choice. In almost all cases (including a team I am working with now), the root issues are lack of discipline around a process, failure to understand scope, failure to understand resources, and failure to understand product quality. Good tools certainly can help.
Bruce Benson • Andy,
Absolutely. I’ve seen too many instances where the “solution” to an organization not working well was to implement a new tool … and I’ve never seen that be successful.
In the same vein, I’ve seen the same idea where the solution was to implement a brand new process, because the old one was not working. This worked no better than efforts to implement new tools (usually with a built in/assumed process).
Instead, where we’ve been the most successful was to take the existing process and get people back to doing it completely the way it was intended. Further improving the process after that was often much easier, because folks now once again understood fully what was needed and why it was needed. Once we had a good working process and a clarity into why it worked well then bringing in tools was almost easy and provided significant benefits (i.e., got a lot more done, faster and with greater accuracy/quality).
Excellent point, thanks.
Comments from around the web:
Jeffrey Brehm • When I was an IT Project Manager in the USAF, I often had to take on that “extra role” of “Requirements Management” as well …
Often, a department would request PC support, but not be aware of other simple things, like power consumption for their electrical circuits, cooling issues for their rooms/buildings, and even that we did not supply “desks” for those new PCs to reside upon! We often had to walk folks “through the process” even though we had published (and advertised … then _re-advertised_, etc.) HOW to go about requesting new IT-Support Equipment items. The “upside” of this constant (and “new”) interaction? We often got “public kudos” for our “personalized customer care” from those folks!
Bruce Benson • Jeffrey,
Yes, I often had to “expand” my job to encompass everything I needed to be successful in our project.
Of course, some people just don’t take the time to research and understand, they just jump in. This is not always bad, but it can drive one crazy when we are trying to provide more service to more people, but they would rather carry on an extended conversation and interact than just get the job done (Ok, I’m often guilty of being high tech without enough high touch).
The good news is you got positive feedback and while that makes it more enjoyable, you still had done all that work to develop, publish, advertise, advertise, communicate, remind, advertise, teach … and may not have gotten the ROI you wanted on all that effort!
Great example, thanks for the feedback.