Stories by Anonymous

Projects that are terminal need to be shelved

When you have less, you have to do less. High on your priority list should be to invest as little time and capital as possible on losing propositions.
Of course.
Some losing propositions are hard to spot, but many are easy to identify. High on the list are projects that have no chance of success.
And by "success", I don't mean completion. It is easy to complete a project – well, no, it isn't. Relatively speaking, though, it is easy when you compare what is required to complete a project with what is required for the project to succeed.
Here's the difference: Completed projects produce all of the deliverables described in the statement of work, in accordance with their specifications. It is nothing to sneer at; accomplishing even this isn't easy. But completion doesn't matter, unless the deliverables are put to productive use in ways that change and improve how the business operates. That is what is required for success.
So how you can identify projects that will never succeed? Here are some indicators.
Large size, long duration: Any project with more than seven core team members and a completion date more than six months after its launch date is questionable. Any project with more than 20 core team members and more than two years to get its work done has a chance of success that is technically greater than zero – but not by very much.
To be fair, you probably should not kill these. What you should do is break them apart into a collection of separate small projects, each with no more than seven core team members and six months from start to finish. You won't officially be doing less with less, but you'll be doing the same with less, because two-year projects engender a relaxed attitude. They also let slackers hide behind the herd. So by breaking sizeable projects apart, you'll get more out of each staff member.
While you won't be doing less with less, you'll be doing the same with less – not a bad result.
No sponsor: Sometimes it is easy – no business executive was willing to step up to the plate and sponsor a project, and because it was important for the company the CIO (you?) had to do it.
Forget it. You'll be able to bring the project to completion. But you won't be able to bring it to a successful conclusion, for a simple and obvious reason: A project's deliverables are just means to an end. The end – the goal – is business change.
Business change is hard enough when high-level executives are willing to stick their necks out and take risks to make it happen. If no business executive wants change enough to sponsor the project, it won't lead to any useful result. Ever.
Bring these projects in front of the executive committee (or whatever group is responsible for project governance) and suggest, politely but forcefully, that since nobody seems to want the project's results enough to serve as sponsor, the company should invest its resources in something else that business leadership does want.
Bad sponsor: Sometimes it isn't so easy. Sometimes a project has a sponsor in name only (SINO). These are easy for a project manager to spot. The sponsor is never available for update meetings, ducks important decisions that are beyond the authority of the project team, fails to commit members of his or her staff to the project (or does commit them, but doesn't make sure they show up when they are needed) and informs the project manager, when issues arise, "That's your problem and I expect you to solve it".
SINOs are the people who figured out while advocating bold change is a career builder, implementing bold change is the sort of risk only losers take on. When the project wraps up, SINOs will explain that the deliverables don't do what they need them to do, blaming the project manager and project team for the mismatch.
Dealing with SINOs won't be easy. As a class, they're better at company politics than you are, so you have to find a way around them that doesn't force you to outplay them at their own game.
Your best bet is to promote a new philosophy to the executive committee. Because all projects are about business change, all projects must include the tasks, deliverables and participation required to make business change happen. It should be an easy sell. Once you get their approval, instruct your project managers to make the necessary changes, which means the project plan will now include specific tasks that have business participants' names on them.
If they don't show up, you can recommend to the executive committee that because the SINO clearly can't spare enough staff time to make the project successful, the company is better off cutting its losses than continuing.
No point: In the end, businesses experience only three forms of benefit: increased revenue, decreased costs or better-managed risks. Any other supposed benefit is either a means to one or more of these ends, or it isn't a benefit at all.
It is up to the sponsor to identify the benefit, commit to it, figure out how long it will take to show up, and explain how everyone will be able to recognise the benefit when it does.
Cost-cutting is the easiest to measure, of course, but that doesn't make it the most important – revenue generally wins that award. Regardless, if the executive committee doesn't already enforce the discipline of "no revenue, no cost-reduction, no risk management, no project," then it should. Encourage this.
You already have less – primarily, less staff, so doing less is not an option. It is an inevitability.
And if you're going to do less anyway, the first items to toss are the ones that are worthless.

In outsourcers we should trust – not

I’m a lawyer, but at every firm I’ve ever worked, I’ve always ended up as the unofficial IT guy. It’s not that I don’t have enough to do, but since I seem to know more about IT than many of the people who are paid to provide it, I find it hard to sit by while my colleagues struggle with problems I know how to solve.

Subverting IT’s enemies

I work as an IT applications manager in the financial services industry. My organisation faces the typical systems integration challenges, outsourcing peril and budget issues — all in addition to a surge of mergers and acquisitions and the need to manage compliance with standards such as Sarbanes-Oxley. While these challenges present significant stumbling blocks, I’ve come to believe there’s a far more dangerous enemy lurking in the shadows: bureaucrats who seem determined to ambush our IT teams and snipe at us under the guise of “enhancing legitimate process”.

Recipe for a development disaster

The Television Station had been using a home-grown interface, and it was our job to replace it. With a US$500,000 (NZ$713,000) budget to work with, I thought we had a good chance of doing it right — and I looked forward to a challenging project. Little did I know!

Inside the project from hell

I spent my first seven years in the IT sector as a midrange consultant, doing custom programming for IBM AS/400s. Years of successful projects left me confident in my skills — I did everything from warehouse management systems to accounting. I guess you could think of it as custom ERP, but long before ERP became a buzzword.

A rogue's gallery

It takes all kinds, as they say, and believe me, I've seen 'em all in the past 30-plus years.

Title entitlement

FRAMINGHAM (10/08/2003) - Currently, I'm the VP of security at a global corporation, a title I've worked hard to get and one of which I'm proud. But all the talk about CSOs has made me think about my role here, how our department's profile has changed in the past few years, and how such a title might convey top management's commitment to what we're trying to accomplish. Frankly, I wouldn't view it as a promotion, and this is not about more compensation. I think a title change to CSO represents a logical next step in the evolution of corporate security within this company.

Scare and scare alike

Okay, so we've all adjusted to the colour alerts put out by the government. But what do they really mean to us? And, more to the point, what do we really mean to them?

The best defence is a firing offence

I've learned two important rules since becoming a chief security officer (CSO). One: You can't argue with a technology expert. And two: You've got to argue with a technology expert.