This is really about project management, trust me.
"The client is screaming bloody murder." Bob was sincerely agitated. Not his normal "we have a million dollar deal on the table" passion, but honest to goodness agitation, beads of sweat and all. "They rolled out the portal in their China office and all hell's broken loose. They ordered their long lead time parts to arrive on March 11th. When the parts didn't arrive, they called their supplier who happily informed them the parts would be delivered on November 3rd, just as ordered."
Across the table, Jake nodded sagely. "Well that makes perfect sense. "
I'm pretty sure normal human beings can't do what Bob did with his eyes right then. "Makes sense? They are going to be late delivering their Nonesense Tablet by six weeks and you're telling me it makes sense?"
Jake leaned back in his seat. I can't swear to it, but I think he was enjoying this. "Well yeah, the portal is a US only design. China uses Day, Month, Year date format. Here in the States we use Month, Day, Year. So when we write March 11th as 03-11, someone in China thinks you just wrote November 3rd." Jake then leaned forward looking at Bob, "We raised this back during the planning phase of the project, remember?"
Well I didn't remember, but I hadn't been put on the project until a week after the plan of record. Bob's face showed no small amount of confusion as well. Jake, sensing the confusion explained.
"When the portal was defined, it was clearly stated as being a US only product. It isn't currently programmed to support other countries. That doesn't just mean the words are in English. The entire system is. Date formats, number formats, post code formats, UI sized for English only and so on."
Bob let his head fall forward, only barely catching them in his palms. "Okay, so its 'As Designed.' How long will it take to make a Chinese interface?"
"I'd say about six months."
"SIX MONTHS?" Bob nearly hit the roof, his eyes doing that very unnatural bugging out again. "I just want a Chinese interface, get the someone who speaks Chinese to sit down with the UI designer. It shouldn't take more than a week!"
Jake shook his head. "It's not that simple. We didn't code the product to be internationalized. Remember you had us remove that work from the project, so you could save time?"
"That was two weeks!"
Jake nodded, "It was. And if we'd done the work then. It would have only taken two weeks. Trying to fix it now means we have to rip everything apart. Think of it like a big truck trailer. The box you want is all the way at the front of the trailer. We have to pull out everything else to get to it."
Bob dropped his head into his hands again. He began to quietly sob "six months… six months… six…"
Hogarth dropped himself into the seat next to me, casting a sympathetic glance at Bob. "You know, internationalization is a lot like project management?"
I turned to look at my gorilla, "Come again?"
Hogarth grinned, "Yeah, think about it. If you wait until a project is in trouble, or even just in development, before you assign a project manager, you're already fighting an uphill battle. Look even bigger than that. How many start ups never make that jump from start up to sustained business because the structure they built as a start up isn't sustainable? By the time they realize they need to change, it's too late."
When is too late?
Making sure you can internationalize your software is a classic example of planning ahead to save yourself a lot of re-work down the road. If you don't make your code double byte compliant, you can end up having to re-architect from the ground on up. What could be a little extra work, during development, can require a complete disassembly of the car, just to put a missing screw into the middle of the engine. Remember how big an issue it was to fix all those Y2K computers that had two digit years and needed four digit years? Same concept.
I18N also gives us a great example of "how hard can it be?" Making your software work in another country can be a very complicated and convoluted process (Check out the scope section of the Wikipedia entry on I18N). It is easy to just brush it off as changing the language on the screen, when in reality making your product work in another country can be an entire product of its own.
So as Hogarth has said, "internationalization is a lot like project management." And that begs the vital question of "when do you bring a project manager in?"
The PMBoK asserts it should be in the project initiation phase. Reality, however, can be a lot different. This is one of those times when I unequivocally side with the PMBoK.
Most of us are probably familiar with the statement "no, we're not ready for that yet," or "I think it's too early to worry about that." Have you heard the line "This project's just started development, we're assigning you to be the project manager?" Or when you inquire about a new project did you hear "Oh it's way to early to get project management involved. We are just hashing out ideas?"
There is a measurable part of society that sees project management as little more than a schedule tracker and meeting holder. This perception places project managers in a non-essential role. If you have one, that's great. But if you don't, just have the development manager, civil engineer, etc. do it in his spare time. It's an add on, not a full time job.
Not everyone sees it that way, and the last ten years have seen this belief drop off considerably. However, that does not make it all a bed of roses. Even when project management is seen as a vital function of a project, the question of "when" remains a troubling little conundrum.
Most start ups don't have dedicated project managers. The general style of a start up calls for jack of all trade employees that can do many different jobs. Particularly in software you hear things like "we're moving to fast," or "we need to be super flexible right now." At some point a successful start up has to cross the chasm from start up to predictable business. Smart start ups hire a project manager at this point. They recognize things are changing and they make an effort to take control of that change. I've seen far more start ups that don't. It is not until deliverables start dropping left and right, commitments are not made and half the company doesn't know what the other half is doing, that they bring in a project manager. By this point, things are so bad that PM is going to spend most of his time in fire fighting mode, fixing the problem of the hour and not making sure the company can execute the entire project.
Similar things happen in many big companies. A product has been fully mapped out, resources assigned, a schedule created (usually based on the desire for a ship date, not realistic estimates), before a project manager is assigned to "manage" the project. The poor PM isn't managing the project, he's one step ahead of the avalanche trying to steer it away from the sleepy alpine village.
Great organizations recognize that figuring our how to do things right, to start with, can save much more time in the long run. The "myth" that one hour of planning can save eight hours of work, has been proven true time and again. Great organizations recognize that you should get the experts on running a project involved from the get go. Project management reaches all the way back into even the wild idea stage. Whether you call it project management, program management or portfolio management, having someone who understands how to get a project from A to Z involved from the start can help to expose issues early and ensure everything that is needed is ready, when it is needed.
In a recent project I served as facilitator to the product management and product architects. The product wasn't even an official project yet, but they knew that in order to be approved as a official project, they needed to treat it like it was real. The output from that meeting went on to become the official specifications for the product. I've also worked in a company where I sat in the strategic roadmap meetings. These meetings would be planning out releases that were no more than ideas on PowerPoint slide.
What's the magic bullet to convince a manager, organization, company that they need project/program resources from the beginning? Unfortunately, like so much of project management, there is no silver bullet. I've used the internationalization example to good effect. Another that works well in, concert with Agile, is the GPS example, "Do you turn your GPS on when you start driving or when you think you should be there?" I've tackled this subject, from other angles, in my "Gorilla with too many hats" and "Project Managers are SMEs" blogs.
As always, relationships matter a lot. You can't force process or a project manager down someone's throat. But develop a good relationship, and like Archimedes and his lever, you can move the world. The biggest thing we can all do, is be successful in early project engagements. Industries learn, and if enough projects are improved through early project management involvement, then that it will become more common.
You might not always be able to get in on the ground floor of a project (or start up), but at the very least you can be aware of the additional pitfalls you're going to be facing.
Joel Bancroft-Connors
Veteran, the project management wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP
Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.
Posts
