Dear Bob ...
We have a legacy MRP system that is the backbone of our company. That is, it's the source for 90-plus percent of the data we use daily. I was hired, in great part, because of my knowledge of this system; I worked for the vendor of the system some time ago and wrote a lot of the code in use today. This legacy system is not sexy, but it works.
[ Want to cash in on your IT experiences? InfoWorld is looking for stories of an amazing or amusing IT adventure, lesson learned, or tales from the trenches. Send your story to offtherecord@infoworld.com. If we publish it, we'll keep you anonymous and send you a $50 American Express gift cheque. ]
Over the years, we've added several GUI front ends to make it look better, and I was instrumental in creating the interfaces that allow them to work in real time with the legacy data.
Lately there have been several new front-end systems added whose initial launches have been dismal failures due to the lack of consultation with me, the MRP "guru." Recently I had to cancel a scheduled vacation because our applications department was rolling out a new front end. Since I hadn't been notified of this, of course the "hooks" didn't exist and I had to come in to create them.
Just today, the lead programmer informed me that instead of the three transactions originally specified for the interface, there is a fourth one that needs to be handled; apparently, this was known earlier this week, but I was only told of it today. So here I am, coding up that change.
I work in operations, not applications, but I have spoken to my boss and the applications manager about this situation in the past, to no avail.
Aside from slapping them upside the head (mentally satisfying but probably of little use otherwise), how can I communicate to my boss, the applications manager, and -- if need be -- the IT director that this type of conduct hurts everyone? After all, applications looks bad when new software rollouts are ill timed and ill prepared; the company suffers from the wasted effort and multiple starts and stops; and I'm forced to rearrange my schedule to accommodate these last-minute issues.
- Excluded
Dear Excluded ...
I can approach your question from two angles: how the organization should behave and what you can do about it.
Regarding how the organization should behave, you've identified the symptom but missed the root cause. The symptom, of course, is that project teams don't involve you until far too late. Here's a guess: If they bring you in late, they probably bring other "subject matter experts" in late, too.
In other words, the company's approach to project staffing is, if not broken, at a minimum seriously bent. What needs to happen is that every project staffing plan should include, in addition to the core group, an extended team composed of employees like you -- workers with special expertise, who will end up with task assignments that should be built into the project schedule, not spotted as part of the punch list compiled just before rollout.
That's what should happen. The next question is what you can do to make it happen. The answer isn't slapping people upside the head, tempting as it is. The answer is, in fact, probably nothing. The way most organizations behave, only those who are officially part of a process or practice are allowed to have something to say about how it can be improved. If anyone had an interest in what you and other stakeholders had to say about the process, project managers would host postproject reviews where they'd ask and take notes.
If you want to give it one more try anyway, your best shot is to ask for some time with the head of app dev. In your meeting, you need to raise the issue not in relation of when to involve just you, but in terms of your having noticed that quite a few project tasks end up pushed into request queues or handled as last-minute crises, when they should be built into the plan. This would be a good time to reference one of the ironclad rules of effective project management: If a task isn't on the plan, with a clear start date, deadline, and assignee, that task won't get done on time.
Maybe the app dev manager will be interested enough to something about it. But frankly, the odds would be much better if you reported into app dev instead of operations.
- Bob
This story, "The perils of slipshod project management," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.