One of the hardest decisions that the IT department faces was highlighted in a very lively Regcast a few months ago. Terry Dewhurst, the streetwise director of transformation at Lastminute.com, talked about how hard it can be to call time on a project that is on track to deliver something that nobody wants any more. This can …
Isn't this the IT director's job?
As the name implies, they are there to direct. To strategise, to have the big picture, to know which direction the biz and the IT industry is headed. Most important of all, it's their first duty to be able to communicate the vision-thing to the minions and also to the shareholders.
If a project request doesn't come with director-level sponsorship, so it can be traced back to a corporate strategy somewhere, it's both reasonable and necessary to question its existence.
it's also the IT directors job to stay aware of shifts in high-level directions, innovations and project costs/progress (at least to the nearest million, anyway). So if a project does seem to be mired or directionless, the sooner the IT director grabs it by the 'nads and/or cans it, the better. That's what they're there for - it only takes one email, and it's why they get paid the big bucks.
Well, it's one thing to say "this is the director's job", it's another to communicate the information effectively. I'd argue that this is the main strength of using a software based solution, the ability to get the information out the heads of one or two people, and make it available to the customer facing roles.
Working on a support desk for an in-development piece of software, I'm often faced with issues where it needs a fix from the developers, but have absolutely no way to estimate their workloads without bothering them and taking them away from their current work.
"Bothering them and --?"
Is it not reasonable to suggest that managing the developers' workloads in the sense you describe should be up to the developers themselves, possibly in the person of a manager, lead, &c.?
Put another way, if by "support desk" you mean client support as seems likely, are you seriously saying that in addition to dealing with the clients' difficulties, they also make you put up with worrying about how the developers are spending their time? As a sometime developer myself, I have to admit I find that idea embarrassing even by proxy.
I suppose I ought to submit a Project Feasibility Study Request...
... regarding the implementation of a Project Portfolio Management system.
I will support your move to form a task force for the project study.
Yay, two bwand mew buzzmords to waste meetings on. Yes, having your projects and services and whatnots and gubbins very clearly listed and rated and methodologised is all and well. The thing is, of course, this is all just as useful as six sigma, prince2 (no dot-oh there, slackers), itil, what-have-you.
What we're looking for is, simply put, good management and administration. The proliferation of the buzzword-y slivers of takes on that on subsets of the total job means that most of us have less than a full clue. (Thank you cap'n obvious.) Yes, we have a long way to go. However, the biggest trap along the long way is believing your own bullshit.
That doesn't mean the subjects of the article aren't useful ideas. But they're certainly not big enough to get all a-buzz about. Or if they are to you, well, I'll leave that as an excercise. The problem with the article is, of course, it's only the buzzwords and some spin sauce, nothing substantial.
Not surprising since the author is, if memory serves, one of those el reg brand whalesong dynamics guys propping up the sushi industry. In a way that's commendable, or perhaps just masochistic, of him to invite comments from a notorious hot air-deflating bunch of commentards.
These things are great - if you understand the principles behind it, and are willing to use it fully. Otherwise, it's like going on a low-fat diet for lunch, and a low-carb diet for dinner - just one more thing to keep track of, without actually fixing anything.
The key is "backed at executive level." From my experience, the most wasteful, useless projects are those that are handed down from on high, not those brought in by users or decided upon by IT staff. And what self-respecting executive will kill their own pet project?
Well actually low fat diet for lunch and low carb diet for dinner (or the other way around) is exactly how the Montignac diet works: it's based on the principle that fats are stored more easily when they are combined with carbs so making sure you don't eat them at the same time will make you lose weight while alternating low fat meals with low carb ones will ensure that you have a balanced diet with no deficiencies.
Having said this, I agree with you in that the key is "backed at executive level." Same for Agile, it only works if it's done properly and backed by the execs.
Sure it's their job, but how many are actually doing it?
I think that's the main focus of this article. There are many companies where the IT Director gets mired down in the day-to-day dramas that often come from other managers who want pet projects done. Some companies don't even HAVE IT Directors, just simply "supervisors" who basically say "Yes, this is important, no this isn't..."
This is a great article to remind IT Directors, or those supervisors who find themselves in a Director's position, that without them overseeing and personally approving the projects from the word go, there can be a lot of fragmentation in the company over what needs to be done and why.
So in short, is it the IT Director's job? Of course. Do they often do it? Of course not.
I submit that is only barely relevant.
If read that way, buzzwords like these are ways to "throw the elephant", force good management practices on the incompetent above you. While useful to make your life marginally better in the short term, it's a poor strategy in the long term.
As people taking care of hardware know or ought to know, the most expensive part is the one that neither works well nor is actually broken. At some point it's more cost effective to make sure such a culprit is actually broken so as to be able to replace it. Poor functioning of people is no different, though the costs are actually higher; people get promoted.
How to avoid having to throw the elephant? I leave that as an excercise.
Could not agree more
Yep, some more buzzwords for bullshit bingo. If you need either PPM or SPM chances are your management are completely disconnected from the business and usually their own staff. Instead of facing the realities, they get consultants in for more bullshit bingo in. The upshot will be:
* Introduction of a PPM/SPM at great cost
* Mismanagement of this system, ensuring that it delivers results supporting political bickering
* Increase of management overhead
* Reduction of "doers" on the shop floor.
Which leads to the classical (and no longer funny) management line of: "The business asked us to deliver more. Therefore, we reduced the number of people doing the work, increased governance, bureacrazy and monitoring; ensuring that the remaining doers have significantly less productive hours in their day. We are now expecting to see a steep increase in departmental productivity. If this does not materialise, we will reduce the number of doers further and increase governance."
Simon trolling for new ideas?
Sounds precisely like the stuff of which BOFH episodes are written.
additional expenditure will be required
---- installing large freezers in the basement and instituting a weekly rib-roast barbecue (to move accumulating `inventory')
where's the BOFH icon when you need it? The pint of lager will have to do.
Not going far enough
Businesses in general, not just IT, need to embrace project portfolio management as a strategic tool. Functional management, based on 19th century military organisation and the empire-building that goes with it no longer works - the 'Matrix management' bollocks that is replacing it simply adds cost and confusion. Everything a company does is a 'project' and should be organised and managed as such. The oversight of those projects needs to be at strategic level reporting directly to the board.
Good example of....
Ask the dutch government about this, they love to spend millions on projects on huge projects that get never delivered, or delivered in such a way that nobody can use it, or like in this article they don't need it anymore.
Often build on technologies that was the standard roughly about 10 years ago, around the time they wanted project XYZ and create the design documents. Then they go into very length, often postponed debates about feature XYZ and obvious 'Jan de Boer' also needs his saying and changes which make the whole project even longer. Then the IT company (often a VERY large 250eur/h company that outsources to India/China) will change double because the project required changes and at least 2 years more of development time, of course against a increased rated because, well inflation foo bar bla bla. Obviously, when a project part get's canceled, it needs to be paid in full because it was ordered in the first place, SORRY!!
This meta project management is a clear sign IT is completely and irrecoverably disconnected from the real business. And rapidly on their way up their own chuff.
All this time prioritising the portfolio is pure waste, better to risk doing the odd non critical project and just get on with solving business issues. If IT really doesn't know what is important then they should be outsourced or sacked.
Places that do this also do waterfall project management, and have more managers than workers, and deliver very little, ever. Good opportunity for consultants and contractors, and snake oil salesmen, easy to shine.
Different funding approaches?
The idea in this URL could be adapted to this application. Instead of charity shares, you allocate budget to the various departmental users, and they would collectively buy shares in the projects that reflected their real needs. The IT staff would have clear guidance on their priorities, even though it would really be another game of corporate bean counting.
Sounds like the NHS...and better vending machine, anyone?
In some ways, I agree, Shannon, but it does sound like the new NHS model which, although noble, would only really serve an As-Is operational world rather than a To-Be world. I.e. they may "vote" for the projects that will improve existing, promising or broken projects, but would they improve the strategic direction for a bigger, braver new world?
On a flippant side to exaggerate my point, those departmental users are more likely to vote for a bigger, better vending machine than anything else.
An alternative? Well, a spin on your proposition by giving those users' departments zero budget and make them vote for no more than 80% of their existing systems to keep alive and then get the department heads create the business benefits arguments to actually get the budget. It would also shake them up to be mindful of why they are there i.e. not just to feather their own nests. Then they will have had practice to weight and score new strategic projects.
It appears Pete 2 executed the perfect, text book definition of an IT Director, top marks. Unfortunately, most IT Directors I've come into contact with, including and especially the one I currently 'serve under' are half wits! Allow me to demonstrate;
Director: "Ooh, an iPad, *gasp* so light and shiny!" *Picks up phone and speaks to Head (who's a real life BOFH caricature) "I'm probably going to order us about 300 iPads, make them work on our [entirely Windows] network, mk'bye!"
Something tells me that most people on this comments page knows roughly what happened next.
The next day, a snivelling Head of Department comes up to the Director and says, "Hey, I've just got this new BlackBerry, apparently it does corporate email!"
Director: *Picks up phone* "Make BlackBerrys work!" *click*
And I have a job for another day...it's a cruel, cruel, ironic world.
Sounds so true, but you can get away without providing them ipads but you won't have many friends left and then find directors will purchase anything they want and then demand it be done immediatly thinking it simply chucking a disc into a machine and walla he becomes the hero of the company.
Good document for cut'n'paste...
Thanks for this document - just nicked half a dozen phrases from it to populate my "process" so I can hand it in quickly and get on with some real work.
It's mostly common sense - i.e. if you have a new project you have to do then work out why, how, when, how much and whether it should be sooner or later than the others.
However if (like me) you have 4 bosses/customers to serve then the real sticking point is the last bit - it's possible the IT director could have final say in this but I can't guarantee a space in his diary for every fortnight when the Sprint process starts again. Which means I end up having to get all the bosses who turn up (that is another problem by itself) to agree. Any ideas?