I have a background in software product development, iterative “methodologies”, and the sort of fast-twitch life cycle that characterizes entrepreneurial startups, high-growing businesses, and “lean” process improvement projects. Unfortunately, this style is also favored by departmental developer wannabes, sloppy coders, and impatient Gen-Y newbies that want to apply a consumer products mentality to corporate IT.
<aside>Yes, I’m throwing a bit of a challenge out with that last statement. I understand that as the demographics of my IT team changes, management style must change as well. However, notwithstanding CIO Magazine’s recent deluge of articles urging oldies like me to “get with it”, and embrace Web 2.0 flexibility, there are certain immutable facts that fly in the face of the recent college graduates urged to apply social networking, text messaging, and torrent-enabled IP sharing to the 9-to-5 grind … but I’ll save that for a later post … </aside>
The real challenge is understanding how to introduce this new and different way of thinking (about projects and project delivery) into an environment rooted in audits and controls, waterfall methodologies, and tightly integrated ERP. Nothing wrong with any of these – in fact, for work in and around your run-the-business systems, there’s nothing more comforting than the rigor of requirements, testing, and a controlled promotion process.
Still, many organizations focus on the wrong legs of the Iron Triangle. Let’s assume that budget, if not absolutely fixed, is at least severely constrained (again, we’re not talking about a fast growth company that has money to burn). At this point, the typical IT department – laboring under the twin misconceptions that the customer is always right, and the business understands the difference between wants and needs – dutifully captures all requirements, and work commences until there is nothing left to do. With budget and requirements “fixed”, time is the variable, and projects go on for months.
I don’t mean to sound cynical – sometimes it’s not a question of kitchen sink requirements (as in, “everything but the …”). Feature creep can also set in when folks want to develop code to test for every scenario or use-case. Even something as simple as adding type codes for a given transaction; believing in the power of metrics, folks will come up with a descriptor for every conceivable exception – regardless of the frequency or relevance.
I think the biggest difference between these organizations and their iterative brethren – startups, fast-growth, and “lean” organizations – is a focus on time to value. Established companies have predictable sales cycles, quarterly statements, and six month planning horizons; it’s not about speed, it’s about getting it right.
Established companies start to struggle with time to value when their environment changes. This is when a subtle change in project management style can go a long way towards liberating the locked-in value of these powerful organizations. Focus on that third leg of the triangle, and learn how to manage a project to a date. I have to be done in 60 days – what can I get done in that much time?
Sometimes this leads to a counter-intuitive decision. For example, a make-to-stock company may have established a Microsoft standard for desktop systems, but a new line of custom engineered, make-to-order products may need to hire in a team of Macintosh-wielding product designers that must be productive on Day 1. In the long run, I may need to replace their new workstations, but I’m certainly not going to slow down the launch of a profitable new line while my standards team goes through a lengthy RFP and vetting process.
Another common mistake – or maybe a defensive mechanism for those well-grounded in the status quo. Sometimes people “give up” on the idea of getting projects done in a short amount of time – “nothing happens quickly here”. I maintain that we give up on the idea of getting it done quickly, because we’re not giving up on the demand for 100% requirements. If we insist that the work must be done in 60 days, we will have to give up some of the nice-to-haves.
This is the big change management challenge before us – prioritize time to value over requirements, and focus on the 20% of the work that will deliver 80% of the value.
This Post Has 0 Comments