projects - News, Features, and Slideshows

News

  • Fending off the business case blues

    If you want to hear your employees whine, just ask them to create a business case for their next project proposal. All together now: "That's too much work." "This project is so simple it doesn't need one." "It's a no-brainer, really. You should just go ahead and approve it."

  • 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.

  • Hard facts on ROI for IT projects required

    When the CEO asks the CIO, "What is the value of IT?" the answer is usually something like, "We keep the company running", "We automate most of the functions of the company", "We contribute to the company's efficiency", or "We improve sales". Then the CIO comments about the various systems that do all of those things.

  • Monitoring project sponsors is vital

    It has become an article of faith that projects without sponsors will inevitably crash and burn. However, unexamined beliefs can lead us astray and we need to be thoughtful about how we apply any maxim. In the case of project sponsorship, more is required of us than checking a box on a form and holding monthly status meetings.

  • Tough times cause project postponment, not cancellation

    IT managers have cancelled fewer client computing projects outright during the recession than expected, preferring to postpone or scale them back, according to a Gartner survey of 475 IT administrators at large companies in nine countries.
    "We were surprised to find IT managers find that postponement is better than cancelling projects," says Gartner analyst Andrew Johnson.
    The survey, conducted from late February through early March, found only 12% of IT managers surveyed had cancelled one or more projects since October 2008. The survey also found 29% postponed at least one project and 33% implemented at least one project at a reduced rate, Johnson says. Respondents were allowed to answer in multiple categories and might have managed several projects, taking different steps with each.
    Overall, 48% of respondents say some of their client projects would be deployed as planned in 2009. By comparison, 43% say they expected to see a decrease in spending on laptops and desktops in 2009, when compared to 2008, Johnson says.
    In earlier research, Gartner said that overall IT spending is expected to decline 3.7% in 2009 due to the recession, with nearly 15% drops in spending on client computing devices, such as laptops and desktops, servers, storage and printing systems. In 2010, Gartner expects IT spending overall to rebound with 2.4% growth, while IT hardware spending will grow 0.8%t.
    Johnson says the survey did not directly ask IT administrators whether they have plans to convert some laptop or desktop users to smartphone or mobile devices. However, he says it is logical to assume some IT managers are postponing laptop and desktop deployments to find lower-cost options, "and a lower-cost option might be a smartphone" for a group of users.
    Some Gartner clients are making inquiries about when a smartphone might be used and whether it is a suitable replacement for some laptop functions, especially for mobile workers, Johnson says.
    The administration of how smartphones are deployed in large companies varies widely. In some companies, IT managers who are in charge of laptops and desktops also administer large smartphone deployments. In other cases, a mobile device IT staff will work entirely separately from desktop and laptop administrators.
    Gartner doesn't see a smartphone as a complete replacement for a laptop for "years to come," he says, even though some smartphones have powerful processors and a wide range of functions for web browsing, using enterprise applications and email.
    "I don't see too many workers brave enough yet to work with only a smartphone on a three-day business trip."
    The Gartner survey found enormous regional differences, with 29% of US-based IT administrators saying they planned to continue client computing projects as originally planned, compared to 18% in France, 85% in China and 64% in India. The average of all respondents globally was 48%.
    Garter also found that the industries most on track with laptop and desktop rollouts were insurance, media, and consumer business services. Those most likely to reduce spending were in telecommunications, wholesale, agriculture, mining, and construction. Those most likely to postpone projects were in retail and utilities. Of the 45 respondents in the financial services industry, only one reported that PC purchase plans were cancelled.
    Johnson says the lesson to be learned from the survey is that laptop and desktop suppliers need to be ready to respond for growth in those regions, along with industries where the postponements were most significant.

  • Five clues that a project is failing

    In these difficult times, lots of projects are getting cancelled, postponed or mothballed. Although these are perfectly normal occurrences in IT, they seem more frequent, swift and stinging now.
    When a project is killed, we like to think that its fate is entirely due to external forces – the swirling, uncontrollable winds of the economic hurricane happening outside. It's not that we're doing anything wrong, we reason; it's just a response to the crisis.
    However, we know better. Many of those projects weren't selected for cancellation just because of sudden shifts in priorities. Some of them were cancelled because there were problems. They were judged unlikely to ever be completed. Or they were expected to exceed time or budget constraints, or to fail to offer sufficient business value even if they did deliver a product.
    So in these austere times, it's more important than ever to recognise project problems early. Thus you can correct them or at least cancel the project before wasting too many resources.
    Yes, we all know that something's wrong with the project when we blow a budget or miss a major deadline, but how can we know before it's too late to do something about it? Here are five early warning signs that your project is in trouble:
    • Management direction is inconsistent or missing. If project leadership has gone AWOL, chances are that things are starting to go in a bad direction. Or, even worse, if the directives you get from management (or feel compelled to give if you are management) change frequently, there's a problem. If a project either lacks direction or can't maintain a reasonably consistent course, it's unlikely to get to any desirable destination.
    • Project management and business management seem disconnected. Even if a project does get consistent direction, if that direction seems to be at odds with business management's desires, there's a problem brewing. In political battles between IT and business management, business management usually wins, even if it takes a while. I don't hear too many stories about the great political triumphs of IT managers over their users or clients.
    • The team lacks a commitment to clearly articulated and commonly understood goals. Every project has a goal or two. They may be clearly stated or only vaguely discussed, but it's rare for any business to shell out lots of money for something that genuinely has no purpose. That said, it's common to presume that the purpose of a project is so obvious as to not be worth articulating. That's unfortunate. It typically leads to misunderstandings and inconsistent presumptions about priorities. Eventually, poor and inconsistent tactical decisions undermine project progress.
    • Team members don't listen to one another. Even when teams get along personally, team members don't always listen well to one another. This tends to lead to chaos as people fail to coordinate activities and make the compromises necessary to enable projects to move ahead.
    • The team is in a state of discord. Teams sometimes break into competing camps. These can form around honest-to-goodness differences over project direction. They can also form over petty loyalties and personality clashes. Sometimes teams just descend into chaos, with multiple factions or an every-person-for-himself ethos. The state of discord is destructive to progress. It needs to be rooted out. Sometimes, as a manager, you can engineer a reconciliation. Other times, you need to pick winners and losers.
    If you notice any of these things happening on your projects, the time to act is now. Don't wait until it becomes obvious that the project is a disaster in the making. By intervening at the first sign of trouble, you may be able to save both projects and careers from the swift executions going on today.

  • Google projects galore gaining traction

    With a skyrocketing stock price, fanboy hysteria and — most importantly — really useful products, Google is the hot company of tech for the new millennium.

  • Projects need prioritisation and monitoring

    A most visible, and often cited, measure of the success of an IT department is the business success of the projects undertaken and the completion of those projects in a timely, cost-effective manner. Therefore, the successful selection, prioritisation, and execution of IT projects plays a large part in determining the overall success of the IT department. Selecting which, and how many, projects are allowed on the IT department schedule is a critical determinant of the overall success of those projects.

  • There's more to measuring IT than ROI: surveys

    Despite the perception that IT projects today are “ROI’ed to death”, organisations are still struggling to control demand for IT services and allocate scarce resources to where they are of most value.

  • Putting projects in a portfolio works wonders

    Using Project Portfolio Management (PPM) to have an of overview of all the IT projects in an organisation can eliminate duplication, save money and boost the standing of the CIO, according to advocates.

  • Flawed processes break IT projects says veteran

    Even with highly intelligent people working in IT, projects will continue to fail if business processes are not well defined and intimately understood, according to a 20-year IT consulting veteran.

[]