Dear Bob ... I'm the IS Manager at a smallish mid-size company (around $100 million in annual sales). My associate and I support approximately 50 PC users, modify programs, write new systems, plus handle customer service and production tasks when required (heck, I've even driven a forklift in the warehouse!). As you might expect, our project list is long and getting longer. I've spoken to my boss (the CFO) and Dear Bob …I’m the IS Manager at a smallish mid-size company (around $100 million in annual sales). My associate and I support approximately 50 PC users, modify programs, write new systems, plus handle customer service and production tasks when required (heck, I’ve even driven a forklift in the warehouse!).As you might expect, our project list is long and getting longer. I’ve spoken to my boss (the CFO) and there is no chance of hiring more people. One of the projects that has been on the books for a while is automating our shop floor in one of our production areas. Just today, the Direction of Operations (who seems to run the company with the CFO and COO) presented me a proposal from a hardware vendor to place barcode printers and scanners on the shop floor, tracking receipt and production information in an Access data base on a PC (we use a mini-computer for all other production data). This entire proposal was negotiated without my knowledge; however, the Director wants my input.My gut reaction is to tell them to do whatever they want since I’m completely out of the loop, but we all know who will get stuck making this departmental system work with the corporate server.My questions are: 1) What should I do in this particular instance? Fight them tooth and nail over this system? Humbly accept the inevitable and embrace the system? Something in between? My plan is to point out the flaws (like no interface to the corporate server) and steer them to a more acceptable (to me)alternative, like a system on the corporate server.2) How can I prevent these end runs in the future?– Run over Dear Overrun …You’re asking the right questions: How to deal with the immediate situation and how to prevent recurrences. And asking the right question is probably 90% of getting the right answer. Here’s another 5% – you’ll have to fill in the rest yourself based on the personalities involved.For the immediate situation, I’d recommend that you give everyone the benefit of the doubt. After all, they aren’t presenting you a fait accompli, just a proposal. Assume they aren’t practiced at the art of defining proposals and soliciting responses, which means that they didn’t exclude you from it at all – this is their version of involving you. Now that you’re involved, I’d suggest the nearest thing to a panacea I have. It’s called “Getting all the liars in one room.” (It isn’t that the stakeholders are really liars, of course – but it can sure sound that way when you deal with each of them separately. That’s why you need to get them all in one room.)The agenda:* Review previously identified requirements * Discuss additional requirements – architecture and integration (this is where you get your oar in the water)* Analyze vendor responses* Develop a go-forward plan The identified requirements part is to get you up to speed, and to make sure everyone in the room is on the same page.Officially, the additional requirements part is IT-related. It is, however, also your opportunity to get everyone thinking about issues like how well the proposed solution will support desired manufacturing processes, the implications of a stand-alone solution, and the fragility of an Access database in a production environment.The analysis of vendor responses is where you get to ask whether they solicited multiple solutions, and if they didn’t whether it might be a good idea to do some bet-hedging. If nobody other than you found serious limitations with the proposal they already selected, accept it gracefully. It’s in the go-forward plan, assuming everyone recognized some limitations with the process they followed, that you can suggest, diplomatically, that for future projects you can help facilitate a smoother process by participating right from the start. Depending on how persuasive you were regarding the current proposal’s limitations, this is also where you figure out whether and how to solicit proposals from other vendors, or what kind of integration the new application will need and where the resources will come from to build it.This is the start of the long-term solution: Continue to position yourself as a participant in planning solutions to business problems with every executive in the company – not just through formal meetings like this one, but by taking them to lunch, buttonholing them in the hallways for informal conversations, and suggesting possibilities they might not have considered on their own for improving how their areas operate.One last bit: A separate meeting with the CFO might be in order, where you point out that whether you add staff, you develop relationships with IT staffing companies, or operations contracts with a vendor independently, the cash out of pocket is roughly the same, so you’d like to revisit the IT staffing question from a new perspective: Not whether you can add staff, but how can you and the CFO make sure the company has the right level and kind of IT resources to support what the business needs … and even more important, how can you tell what that number should be? The more you can do to make the CFO a collaborator instead of someone who passes judgment on your requests, the closer you’ll be to your goal.– Bob ——– Technology Industry