We're always looking for a better way to do things, whether it's how we complete a project to how we plan a wedding. There's something to be said for having a routine and doing things the same way, but in the business world, it's those who don't innovate and re-invent themselves periodically that are left in the dust. Take for example how the mighty Blackberry (affectionately "Crackberry" in the mid 2000s) has fallen; each iteration seems to be several steps behind the latest iPhone and Android device (don't even get me started on their failed tablet, the Playbook). But companies are starting to realize they need to work harder and check that work more frequently, and thus begun the process improvement models era. No longer would companies just "assembly line" all the work and hope for the best. Even behemoths in the industry are going back and analyzing each component of their processes and trying to get the best performance for their dollar. And now we have models such as Agile, Scrum, CMMI, and a host of others.
But how do you get the buy-in? In a recently posted article from Esther Schindler of IT World, clients and users tend to really hate improvement models such as Agile. Why? She cites quite a few reasons. For starters, users want budget and technology predictability. It's very hard to get buy-in when users and even C-Level executives don't know what's coming next. This is an important task for R&D and for companies to really take their time in finding out what the best logical move is to make. However, she ties it to another issue which is that the iterative process tends to mean disorganized and never-ending. It may of course depend on the context; something like a Strategic Plan or BHAG (Big Hairy Audacious Goal) should be something that evolves slowly over time, but when it comes to releasing the latest product or service, companies can't afford to rest on their laurels and get hung up on bureaucracy.
There's also the issue of culture clash. Agile trainer Robert Woods mentioned that users now are being asked to collaborate with a developer who can sometimes have zero communication skills. "They try to give input but it's not listened to," says Woods. "They are asked to review and prioritize a backlog but 'What the heck is a backlog?'" People of varying skillsets are asked to step outside of their comfort zone for the betterment of the project, but that doesn't necessarily correlate to a better process. This can also lead to not correctly identifying your stakeholders, which means that you might not be working on the appropriate tasks for the work.
Process improvement is still a "buzzword" out there in the world, though. Another IT World writer, Phil Johnson goes on to describe how anyone from public radio employees to construction companies are adopting process improvement models to do things better. In fact, Johnson mentions how it might be easier in other fields to implement these improvement models because those in software disciplines are often ingrained with the old Waterfall methodology, which means working towards a long term goal in steps without much recursion, if any. And if anything can be said for that, people are also very slow and hesitant to make changes. If you think about the software development world, a client asking for even a small change might mean having to write a portion of code (or the whole application) from scratch again after it has been completed. Most of these iterative processes allow for that, which is a double-edged sword: you can have a piece of software that works as it was stated to work, or you could have something that's not quite as polished and may require patches and updates because the needs and goals will continue to evolve and change. However, the latter does allow the end-user to get what they want and not be cemented with something that might not meet their needs at all.
The big take-away is that these processes are long and grueling. This isn't just an easy implementation. It will take lots of meetings and planning to get the work complete, and just hoping that it will make life easier and the project come out faster is an unrealistic mindset to have. You may be faster to market with your product or service since you're continuing to evolve your end-product, but that doesn't mean it will reach its completion any sooner. Process Improvement Models are also not perfect at predicting reality; often there are many outside factors that will deviate from what your plans are, and even the most effective Project Manager will not be able to account for all circumstances.
I'm not here to encourage people not to use them, but rather encourage people to see them for what they are and not expect miracles. Just because you improved processes at one junction doesn't mean that the results will make sense downstream. Having this myopic view of process improvement can be hazardous to not only a company's projects, but their long-term aspirations as well.
PIM's are a tool, much like a hammer or a screwdriver. If you use them properly, you will realize how much easier your job becomes. But if you rely on that tool to work outside of its purpose, it can certainly lead to disastrous results.
1. Why Your Users Hate Agile Development (and what you can do about it) (IT World)
2. You may kiss the bride and update the Scrum board (IT World)
3. CMMI - High Maturity Misconceptions and Pitfalls (Slideshare)