The Windows 10 release means big changes for the OS. Here’s what SMBs need to know.
In a historic move, Microsoft will release the latest iteration of their Windows OS, Windows 10, as a free upgrade for existing users.
This removes at least one barrier to adoption among businesses, and it could be particularly advantageous for small to mid-size businesses (SMBs) by helping Microsoft stay competitive in the SMB space against Apple and Google who are ramping up their efforts for this audience.
The Windows 10 release signifies a shift in direction for Microsoft as its new leadership gains traction. However, it also brings many changes to the product itself.
Here’s what your SMB needs to know about the latest Windows release.
1. The upgrade has an expiration date
The official release date of Windows 10 has been listed as July 29, 2015. But, there’s so fine print. According to Gartner vice president Steve Kleynhans, it’s essential you do your research to determine if it is a good deal for your company within the timeline.
“Certainly it is nice getting the upgrade to Windows 10 for free, but it requires that you move in the next 12 months,” Kleynhans said.
2. Windows is now a service
Software upgrades used to be a major source of revenue for Microsoft in the past, but with Windows 10 comes a new model. Users will receive updates to the OS as time goes on.
“Windows 10 will be a ‘final’ upgrade that receives three to four upgrade packs a year that include new features,” said JP Gownder, a vice president and principal analyst with Forrester. “Windows as a service means you won’t be stuck with some 10 year old OS, as many were with XP, but it does require a little rethinking of resources, even these upgrade packs require some testing along the year.”
3. You have to be ready for the updates
As you consider whether or not to make the upgrade, it’s important to consider if you can handle the deluge of service packs that will come your way in this new system, Kleynhans said. You won’t have much time to “settle” into the new service packs before the next one comes.
“It will constantly be moving forward,” Kleynhans said. “You need to monitor it and test to see how it performs in your environment and decide when it is ready to fit into your environment.”
4. You can only upgrade from certain versions
To qualify for the Windows 10 upgrade, you must be upgrading from a Windows 7 or Windows 8.1 device. The availability of the upgrade for Windows Phone 8.1 varies by manufacturer, carrier, and operator. You’ll also need to have Windows Update enabled. Many of the enterprise versions are excluded from the upgrade offer, so make sure you check if yours is compatible.
5. There are different versions of Windows 10
Depending on your starting OS, you will get a comparable version of Windows 10 when you upgrade. Windows 7 Starter, Home Basic, Home Premium, and Windows 8.1 (4) will yield Windows 10 Home. Windows 7 Professional and Ultimate, and Windows 8.1 Pro and 8.1 Pro for Students will yield Windows 10 Pro.
6. Follow best practices for deployment
Just because Windows 10 is a new model for the OS doesn’t mean that it won’t come with some of the standard deployment pains you may have faced in the past. Make sure you time everything properly to minimize the number of problems you run into.
“OS upgrades, no matter how good, are disruptive,” Kleynhans said. “Don’t roll out Windows 10 right before your busiest selling season, or in the middle of implementing a new accounting system.”
7. Upgrade for security
Especially for SMBs, protecting your assets is critical. If you’re already a Windows shop, upgrading could bring some added security to your company.
“Security threats are only growing, and Windows 10 has some inherent application containerization that makes it more secure than its predecessors,” Gownder said.
8. It doesn’t (technically) require new hardware
While you will need a certain set of specs to run Windows 10 and a set amount of hard drive space, you probably won’t need to update your hardware. However, Kleynhans said, you might need new hardware to make use of new features such as Windows Hello or the advanced security. Unfortunately, he said, in may cases, that hardware won’t ship until later this year.
9. It’s a new user experience
One of the most contentious aspects of Windows 8 was its tile-based design. Some loved it, while others switched back to the standard desktop view immediately. Gownder said that Windows 10 is poised to provide the best of both tiles and the standard desktop, and will be optimized for mobile.
“If you have a detachable keyboard — say, on a Surface Pro 3 — the OS will default to desktop mode if the keyboard is attached, and to tile mode if it isn’t,” Gownder said. “So, it’s smart about desktop vs. mobile usage.”
10. The ecosystem might not be perfect
As we creep closer to the release date, it’s important to remember that although the OS might be ready, that doesn’t mean the ecosystem is. As an SMB, you might need additional support and, with the novelty of Windows 10, you might have trouble finding someone to provide the support right away, Kleynhans said.
Also, just because your key software or application works on Windows 10, that doesn’t always mean your vendor will provide Windows 10 support.
“They might need some time to complete some testing and make some tweaks,” Kleynhans said. “Talk to your software and service providers and understand their plans and timeline as your develop yours.”
CIO salaries in the U.S. average between $157,000 and $262,500, according to Robert Half Technology. But salary is just the beginning. Cash bonuses and equity awards can propel pay packages into the millions. To find out how much CIOs at giant global companies really earn, we scoured the proxy statements of the 500 largest U.S. companies (according to Fortune’s ranking) and found 25 that disclosed CIO pay. Here are the details on their pay packages, organized from lowest to highest paid. If available, compensation for these individuals in prior years is included.
Compensation for CIOs includes cash, equity, perks.
To see all the data in one place, check out our sortable chart of CIO compensation.
A good–or bad–project manager can make the difference between a project coming in on time and on budget and it being a failure. How can you spot a good project manager? CIO.com talked to experts and IT executives to find out.
Just because someone has the title of “project manager” does not mean he knows how to effectively manage projects, as many CIOs and other IT executives have learned the hard way.
So how can you tell a good project manager from a bad one? CIO.com surveyed project management experts and executives to learn what skills are required to successfully manage projects–that is, to ensure that projects are kept on track and stay on budget.
Here are seven skills project managers need in order to be effective and successful:
Skill No. 1: Be highly organized and a good multi-tasker. A good project manager knows how to “manage multiple projects or tasks and track issues on a daily basis,” says Hilary Atkinson, director of the Project Management Office at Force 3, a business solutions provider.
The difference between the success or failure of a project is often “the difference between a project manager who is highly organized and one who is not,” she says. “If a project manager is spending more time trying to figure out where information is rather than productively managing their project, failure is eminent.”
Skill No. 2: Take charge and know how to lead. “Project managers need to be good leaders,” says Lew Sauder, senior project manager Geneca, which develops custom enterprise software. Specifically, “project management is about leading stakeholders and vendors to a successful outcome,” states Brian Lee, partner at Navigate, a management consulting firm.
“Projects need to be led in a fashion that builds consensus while also fleshing out the real risks and roadblocks,” he says. “Effective project managers paint a picture of a better tomorrow and inspire confidence in their team’s abilities to realize that vision. They build credible relationships with key stakeholders to ensure alignment to the project’s objectives and exude the confidence necessary to hold everyone participating in the project accountable.”
Skill No. 3: Be an effective communicator. “Being an outstanding communicator requires the project manager to consistently ensure they are clearly understood by all stakeholders; that all stakeholders understand what is expected of them throughout the project lifecycle; and that all stakeholders communicate effectively with one another as well as with the project manager,” says Dr. Greg Thomas, CMC, PMP and CEO of Roos Technologies International, a management consulting firm.
“Project managers need to be able to communicate status changes, good news and bad news to all levels of staff across different departments,” says Nandi Hayes, an agent at Vitamin T, a talent agency for digital creatives.
“They also need to be able to distinguish who needs to know what, when they need to know it and how that information will be delivered,” she says. “For example, a slight scheduling delay may need to be communicated to internal teams but not to the client if the key client review dates are not affected.”
Skill No. 4: Know how and when to negotiate. “Project managers must be excellent negotiators,” says Brock Boddie, an associate program director at Huge, a global digital agency. “You’re very often dealing with people who have divergent interests from your own or who appear to have no interest in understanding what you’re trying to accomplish and why they should help you or fully participate,” he says.
“A good project manager will invest time to understand and negotiate these relationships and figure out these stakeholder’s interests, so that she can triangulate what will make her project continue to move forward. Without these negotiating skills, you may spoil or ignore these critical relationships, making project success highly unlikely,” Boddie says.
Skill No. 5: Be detail-oriented. “Project management is all about the details–big ones and small ones,” says Aziz Kara, head of Product Management and Design at Xtreme Labs, a mobile app and product developer. Therefore, project managers must be “meticulous about managing the details of every project and the impact each detail may have on the overall project success. Details can make or break a project, and the effective PM recognizes that.”
Skill No. 6: Recognize and solve problems quickly. “Inevitably, there will be times when problems and obstacles arise that involve immediate solutions,” notes Michael Pesochinsky, cofounder and vice-president of GovernmentBargains.com, a free site that compiles and provides information about government auctions. “How a project manager handles these problems will separate him from the others.”
Skill No. 7: Possess the necessary technical skills. To be a good project manager, you “must have solid knowledge of the platforms, software and programs that your company regularly works with, even if your job is not actually technical,” says Joel Gross, the founder and CEO of Coalition Technologies, a Web design and marketing firm.
And “a great project manager needs to have enough technical knowledge about areas of the project to be able to assign themselves to some of the tasks,” adds Bob Herman, the owner of Tropolis Group, which provides IT, mobile and social media management services to companies. Why? “Assigning yourself to some of the project tasks and successfully completing those tasks on time helps you earn the respect you need to successfully manage the project team.”
Once you realize that a project is in trouble, the next question is what to do about it.
Sometimes a project can be saved; sometimes it can’t. In general, the earlier you spot trouble, the easier it is to do something positive about it—anything from making minor adjustments to scope or schedule to killing the thing outright.
“Early warning gives you the opportunity to make small course corrections early,” says Raj Kapur, executive vice president for the Center for Project Management, a project management consultancy and educational organization headquartered in San Ramon, Calif. “The earlier in the lifecycle the issues are found, the easier the team is going to take it.”
The first step in fixing a project is getting everyone to admit the project has a problem. If you’ve spotted the trouble early enough, this recognition can be merely a psychological hurdle. The normal human response is to make explanations and excuses as things start to slip. Often managers and team members don’t want to admit that things are going sideways until they get really bad. Or, alternatively, everyone is so busy doing his or her own job that they haven’t noticed yet.
“Often, team members are disconnected,” Kapur points out. “They’re doing their work head down and so focused on doing their part, they really don’t get the big picture.”
One big help is honesty. “Give your project team the respect of the bad news,” Kapur advises. “Don’t play games with the team. Especially the seasoned professional will see the writing on the wall.”
The next step is to figure out what’s wrong with the project. This usually involves careful examination and a lot of hard, close listening. The question always has to be, “How do we fix this,” not, “Who is to blame?”
“It’s important to avoid blame,” says Frank Gianic, president of PMO, an Austin, Texas, consultancy that specializes in rescuing troubled projects. “One of my first speeches when I come in to a project is that we’re all starting fresh. Let’s not get focused on who did what in the past; focus on the next 30 to 90 to 120 days.”
Gianic says it’s also important to provide some fast, if minor, successes to help rebuild team morale. “Identify some quick wins to help the team feel the project is getting back on track,” he advises. “Typically, you can find a critical path item and work through getting that one thing done. That’s critical. Before the team can start to develop some optimism you have to have that kind of early quick win.”
In the bigger picture, one of the most useful places to start fixing a project is with the requirements. Often there are requirements that can be deleted with relatively little impact on the usefulness of the result.
“The first thing is, do you really need all the things you have in the project?” says Jim Johnson, chairman of The Standish Group.
The reason is what he calls “the law of the long-tailed monster”: “You always build too much of what you don’t need and not enough of what you do need. We’re always concerned with meeting all the requirements,” he says. “What we need to do is focus on the essential requirements.”
ProjectPerfect, an Australian maker of project management software, has a detailed overview of rescuing failed projects.
Sometimes the project emphatically isn’t fixable, at least not at a cost commensurate with the business benefit. For example, management may have lost interest, or the business requirements may have changed. In that case, the best thing to do is write it off. Try to understand what went wrong and learn from it.
2015 Cyber Threats and Trends: What You Need to Know to Protect Your Network Data
Defending an enterprise today is a more complex and challenging task than ever before.
Our personal and professional attack surfaces have never been greater, and they are only expected to grow as organizations and individuals continue to increase their reliance on the digitally connected world for a variety of tasks. Security practitioners must not only protect their enterprise assets, but also guard against threats to their supply chain and other business ecosystems. These threats, coupled with the cyber threat landscape’s continuous evolution in terms or actors, tactics and motivations, have created a situation where organizations must now move toward an intelligence-driven, holistic security approach to keep pace with the rapid changes in attackers’ tactics, techniques and procedures (TTPs).
Nearly 70 percent of IT projects are dogged by cost-overruns or aren’t completed on schedule due to poor planning, poor communication or poor resource allocation. This story assess the impact of the 14 most common project management mistakes and offers ways IT groups can avoid them.
It’s no wonder only 29 percent of IT projects are completed successfully, according to The Standish Group. Project management consultants and software providers say they see IT departments making the same project management mistakes over and over: IT groups don’t follow standard project management processes. They don’t have the right staff working on projects. They don’t assess the risks that could imperil their projects or determine ways to mitigate those risks. The list of mistakes unrolls like a ball of yarn.
The following list of the 14 most common project management mistakes ought to help you pinpoint where your projects are going wrong and measures you can take to improve them. The upside of avoiding these most common project management pitfalls is tremendous. Not only will your project success rate increase, you’ll also improve satisfaction among internal customers, IT’s stock inside the organization will increase in value, and the business will benefit from systems that make them more competitive that get delivered on time and on budget.
Mistake No. 1: Projects lack the right resources with the right skills.
Impact: Proper project staffing is critical, yet improperly allocating resources tops the list of most common project management mistakes. Not having the right people on a project can kill it. “The key to getting a project successfully accomplished is getting the right people with the right skills,” says Joel Koppelman, CEO of project management software vendor Primavera. “All the planning in the world won’t overcome an insufficiency of talent.”
Solution: IT and project managers need full visibility into the skills and workloads of all of their resources, including consultants, contractors and outsourcers, who often get left out of skills assessments even though they’re doing a “huge” proportion of work, says Koppelman. Project management software can provide such visibility into everyone’s skills and workloads.
Once IT and project managers know who’s doing what, they have to figure out how to allocate resources across myriad projects and day-to-day work.
“There are all kinds of organizational models,” says Richard Scannell, co-founder of IT infrastructure consultancy GlassHouse Technologies. “I’ve never seen anything that works well. There’s no easy answer [to the resource allocation question].”
You just have to try synchronizing people and projects as best you can, says Koppelman, adding that one potential solution is to appoint a resource manager who’s responsible for figuring out who will be assigned to each project and for ensuring there’s a fair allocation of talent across projects.
Scannell suggests setting up “tiger teams” where people get taken out of their traditional job responsibility for a year or more to work on a specific project. Ken Cheney, director of HP Software’s PPM Center, recommends assigning resources at a project level as opposed to a specific task level, which he says is much more arduous.
If you’re still hard-pressed to adequately staff projects, you may be able to free up resources by cancelling a “discretionary” project (e.g. one that isn’t tightly tied to the business strategy), says Cheney. He suggests looking at your entire portfolio of projectsyour IT staff is working on to identify ones that aren’t mission-critical. “By stopping those projects and reallocating resources to projects that will have the biggest impact, the organization as a whole can be much more successful,” he says.
Impact: Projects can quickly grow out of control without a savvy project manager at the helm.
Solution: Hire project managers with certifications and the finesse required to manage stakeholders. Matthew Strazza, vice president of services (North America) for CA, says good project managers have to have strong soft skills. They need to know how to facilitate meetings, manage risk and handle a variety of different stakeholders—the business people who are looking for functionality, the IT people who care about security, and the financial people who are worried about the budget.
“If you’re not addressing the financials, managing the budget on a week-to-week basis and notifying the client of any change, you can get into trouble pretty quickly,” says Strazza.
Good project managers also need to possess technical expertise in whatever technology is being deployed, he adds.
Mistake No. 3: IT doesn’t follow a standard, repeatable project management process.
Impact: This is the second of the most common project management mistakes. Lack of methodology increases the risk that tasks related to the project will fall through the cracks, that projects will have to be re-worked, and ultimately that a project won’t be completed on time or on budget.
Solution: A project management methodology helps you tackle projects efficiently and makes you aware of all the activities involved in the execution of a project.
“Having in place a baseline of standards and methodologies will remove a lot of the risk associated with IT projects,” says HP’s Cheney.
Douglas Clark, CEO of Métier, a provider of project portfolio management solutions, recommends establishing repeatable processes for scoping, scheduling, allocating resources and communicating with stakeholders. “Those are the things you want to get a handle on first because they would probably give you the biggest payoff,” he says.
Mistake No. 4: IT gets hamstrung by too much process.
Impact: Too much process makes the project team inflexible, and their inflexibility frustrates stakeholders.
Fumi Kondo, managing director of NYC-based consultancy Intellilink Solutions, once observed an exchange between a software developer and a project manager where the developer told the project manager that he could add extra features to an application with no additional effort. The project manager told the developer not to add the extra features because users hadn’t asked for them. “My response would have been, ‘Go to the users and see if those features are useful,'” says Kondo. “I see nothing wrong with over-delivering if it doesn’t impact the budget or the schedule.”
Solution: Be flexible and communicate with project sponsors and stakeholders.
Mistake No. 5: They don’t track changes to the scope of the project.
Implication: The budget for the project explodes. So does the timeline.
Solution: CA’s Strazza recommends following a formal change request process: The individual requesting the change in scope (e.g. additional features or functionality) needs to explain the specific changes on a change-in-scope document, and the project manager needs to determine how that request will impact the budget and timeline. The project sponsor has to sign off on the change-in-scope request.
Mistake No. 6: They lack up-to-date data about the status of projects.
Impact: You can’t manage what you can’t measure, as Peter Drucker would say. Nor can you coordinate resources or react to changes in scope, says HP’s Cheney.
Mistake No. 7: They ignore problems.
Impact: Problems don’t solve themselves. They fester the longer you ignore them and ultimately compound the cost of the project.
Solution: “If you do something wrong, it’s about how well you fix it,” says GlassHouse Technologies’ Scannell. “Most people batten down the hatches and look up in the month. Understanding when you’re starting to fail and quickly being able to engage as many stakeholders as possible to fix it is critical.”
Mistake No. 8: They don’t take the time to define the scope of a project.
Impact: If a project’s scope isn’t well-defined by the business and IT up front, the project can end up ballooning like Friends actor Matthew Perry in the sitcom’s later seasons. What’s more, IT lacks the clarity and direction it needs to complete the project on time and on budget and meet the business’s expectations.
Solution: Ill-defined projects are best served by a business case and a scoping exercise, says Intellilink Solutions’ Kondo.
Mistake No. 9: They fail to see the dependencies between projects.
Impact: Projects don’t happen in isolation. They’re often dependant on other projects going on at the same time. When project managers fail to see the dependencies between projects—such as staff assigned to one project are needed on another&mdashh;projects get held up. Such slowdowns can have a ripple effect on all projects.
Solution: Take dependencies into account during project planning, says Métier’s Clark. Talking with stakeholders and diagramming the project can help uncover dependencies.
Mistake No. 10: They don’t consider Murphy’s Law.
Impact: Stuff happens, and IT gets surprised by it. Consequently, the project goes off-track while IT tries to clean up a mess it didn’t anticipate.
GlassHouse Technologies’ Scannell recalls a company in the U.K. that his firm acquired, that was moving its mainframe to a new data center. The IT group devoted an entire Saturday to taking down the mainframe so that they could move it to the new data center the next day, he says. While the IT staff were en route to the new data center with the mainframe on Sunday, they ran into a gay pride parade, and they couldn’t reach their destination due to roads blocked off for the parade. They had to drive back to the original data center and put Humpty Dumpty back together again. The lack of planning caused the IT staffers to do more work than was necessary.
Solution: Perform a risk assessment as part of the project planning. With your team, brainstorm what could happen to slow or derail the project, to make it go over budget, or to prevent you from delivering the expected requirements. Then figure out ways you can mitigate those risks, says Primavera CEO Koppelman. “If they sit down and think about those risks, they’ll come up with a pretty good list,” he says. “This exercise doesn’t take a long time, and it’s enormously helpful in understanding the soft spots in a project before it even gets underway.”
Impact: All the time, money and hard work that went into delivering a new IT-enabled capability can be for naught if users don’t adopt the new technology.
Solution: Spend time up front during the project planning phase to consider where resistance to a project will manifest itself and ways to address it, says Métier’s Clark. Identify the stakeholders whose jobs will be impacted by the new capability, adds Intellilink Solutions’ Kondo, and plan how you’ll communicate changes to their processes and workflows with them. Not all of the changes will be negative.
Mistake No. 12: Project schedules are incomplete.
Impact: Project team members don’t know what is due when, which makes completing the project on time a challenge.
Solution: Clark says a quick way to come up with a schedule for a project is to determine all the activities involved in getting the project done (e.g. scoping, getting requirements, testing and implementing) and then attaching due dates to those activities based on the deadline for the project. Project management software can also help create schedules.
Impact: IT sets itself up to fail and gets a reputation for not being able to deliver projects on time.
Clark says IT departments will scramble to accommodate project deadlines set by the CEO. But tampering with dependencies and with the plan only creates more problems that make delivering the project on time even more difficult, he says.
Solution: IT management has to explain to the CEO what it’s going to take to meet that deadline in terms of cost and resources and has to get the CEO to choose between cost, scope and schedule, says Clark.
Mistake No. 14: They don’t communicate well with project sponsors and stakeholders.
Impact: IT fails to deliver the expected requirements.
Project communications need to be catered to the audience, says Kondo. She sees misunderstandings about the scope of a project or a systems’ requirements arise when IT departments hand over a spreadsheet to the business with thousands of lines describing the systems’ functionality and specs. Because the business owners don’t have time to look over such detailed technical documents, they ignore them.
“One side is communicating, but in a language the other side can’t understand,” says Kondo. “Then IT gets frustrated and they say, ‘We described this to them. How come this isn’t what they want?'” (Business analysts play a critical role as the liaisons between users and IT.)
Kondo recommends giving every stakeholder who will be impacted or involved in the project on the business side a high-level overview of the entire project, from design to rollout. The overview should highlight the activities that require interaction with the business and should explain why the business is needed, she says.
In general, IT needs to put more effort into educating the business about the steps involved in executing a project, says Kondo.
“If you have an open dialog about what’s needed, what you’re really delivering, and you have fluidity built into the process, the budget and scope becomes a dialog so if you go over budget, it’s not necessarily a failure,” she says.
Kondo’s firm once worked with a client that was deploying a financial system and whose employees had never been involved in a large system implementation before. When design of the system was complete and Intellilink was beginning to plan for testing, Intellilink explained to the employees why testing was important.
“We told them about different kinds of testing and what they did and didn’t need to be involved in. We talked about why we needed user input, what kind of input we’d need and how much time it required,” says Kondo. “That gave people an idea of why it takes so long to test.”
A widely quoted phrase these days is “software eats everything.” It refers to the great value that software delivers. I believe it also applies to the profound impact it’s making in the services world. Software is disintermediating the industrialized labor arbitrage model and also infrastructure services. Let’s look at the huge implications for the services industry.
How is software eating services? It’s happening in a number of important ways and areas.
Software eating BPO
First, software enables automation and RPA to replace much of what the current industrialized arbitrage model does. Much of this work is repetitive and screams for a more automated approach. BPO work, for instance, bridges the gap between the labor that interfaces between records and the system of records. As I’ve blogged before, software is about to eat BPO labor.
DevOps and software eating infrastructure services
The DevOps revolution’s impact on infrastructure services is another example of software eating everything. A fully integrated DevOps platform allows defining code for infrastructure hardware at the same time as defining code for functionality. Increasingly in a software-defined infrastructure, companies can build an integrated DevOps platform that enables simultaneously configuring the entire supply chain from functionality all the way down to the number of cores it requires to run and test it.
Prior to the DevOps movement, all these steps were labor based, and much of this work migrated into the industrialized arbitrage model. They now become largely automated and software controlled.
Software and virtual services eating infrastructure services
Another example within infrastructure is the infrastructure itself. Five years ago, companies operated in a world where they were trying to move from 20 servers per FTE to 50. Most of the infrastructure service providers succeeded based upon their ability to make that shift.
Today, the services industry tries to get up to somewhere in the range of 200 to 500 FTEs per server. But the highly automated world in Silicon Valley has over 100,000 virtual servers per person. They’ve completely severed the link between people and servers. Again, a dramatic example of software eating everything.
SaaS, BPaaS impact
Another dramatic example of software eating everything is the Software-as-a-Service (SaaS) and Business Process as a Service (BPaaS) offerings. These software-based services offerings completely automate and configure the software, hardware, and business process experience for customers. SaaS and BPaaS completely upend the classic functional model previously used to deliver these functions.
Implications for the service industry
Software eating everything is a relentless focus on different ways to sever the traditional link of labor (FTEs) to service. The dislocation to labor-based businesses will be immense over the next few years as this journey to a software-defined world continues and existing business models struggle to adapt.
A software-defined marketplace will dramatically change the current services market. It will create opportunities for new industries to emerge and force tremendous tension on the incumbent service providers to survive by embracing the change and cannibalizing their existing work.
Often, the difference between success and failure is spotting critical early warning signs that a project is in trouble. Here are a few ways to identify the symptoms.
Usually, when an IT project fails, management is the last to know. But eventually, like a fish left too long in the refrigerator, the failure becomes all too obvious. When the situation reaches that point, your only option is the IT equivalent of pulling everything out of the refrigerator and scrubbing it out with baking soda.
But it doesn’t have to be that way. Conventional wisdom to the contrary, project management is getting better. More projects are succeeding, fewer projects are failing outright, and projects are returning more of the IT dollar invested.
Still, only about one-third of all projects are complete successes. Often, the difference between success and failure is spotting the critical early warning signs that a project is in trouble. Here’s a quick look at some of the earliest symptoms that all is not right with your “fish”—and what you can do about it before you have to break out the baking soda.
Be Reassured: Failure Isn’t Preordained
The good news is that things are getting better. The most widely used measure of IT project success is the Chaos Report from The Standish Group International. The biennial (once every two years) report is based on a worldwide survey of several thousand medium to large companies. “We’ve measured project success every two years since 1994,” says Jim Johnson, Standish Group chairman.
The original study (which is still sometimes quoted as if it were current) was shocking. In 1994, the researchers found that 31 percent of the IT projects were flat failures. That is, they were abandoned before completion and produced nothing useful. Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features.
“As of 2006, the absolute failure rate is down to 19 percent,” Johnson says. “The success rate is up to 35 percent.” The remaining 46 percent are what the Standish Group calls “challenged”: projects that didn’t meet the criteria for total success but delivered a useful product.
“We’ve gotten better for several reasons,” Johnson says. “The whole discipline around project management is becoming more of a profession. We’re understanding the process better. We’re getting more articulate users who can describe what they want better. And we have some very good tools, like UML, that can help the user.”
The Internet plays a role as well, according to Scott Johnson, CEO of AtTask, an Orem, Utah, maker of project management tools.
“Communications can go back and forth quickly,” Scott Johnson says. “You don’t have to wait for a status report meeting to find something has gotten hung up. You don’t have the bottleneck of an individual trying to broker communications.”
Scott Johnson points out that new project management tools tend to be easier to use than the ones of a few years ago. In addition, they often include features such as sophisticated trend analysis that can spot problem projects early.
Another change, Standish Group’s Jim Johnson says, is the use of new project management methodologies in place of the old waterfall model where the entire project proceeds step by step from analysis to final delivery en masse. Both Johnsons are strong proponents of agile project management, which focuses on breaking projects into small chunks and delivering pieces of it fast for user feedback.
Looking for Warning Signs
While the Chaos surveys give reason for optimism, they leave little room for complacency. Nearly one in five IT projects still fails absolutely and more than two in five are partial failures.
What is perhaps more troubling is that the bigger the project, the worse the problems. “Seventy-three percent of projects with labor cost of less than $750,000 succeed,” Jim Johnson says. “But only 3 percent of projects a with labor cost of over $10 million succeed. I would venture to say the 3 percent that succeed succeeded because they overestimated their budget, not because they were managed properly.”
(Perhaps significantly, agile project management is notoriously least effective on very large projects.)
Warning signs are different from reasons for project failure. Common reasons for failure include lack of management support and unclear objectives. Warnings are much more concrete and concerned with the day-to-day running of the project.
The most important early warning signs are intangibles. The earliest signs a project is in trouble are hard to measure objectively, but easy to spot if you watch for them. Two of the most important, Jim Johnson says, are lack of interest in the project and chronically poor communications.
Lack of Interest
Often, Jim Johnson says, a lack of interest in the project’s success results from a lack of real buy-in. Actors may have been pressured or cajoled into signing off on the project without really agreeing to it.
“Make sure everybody really agreed to what the project is going to do,” he says. “Make sure everyone has the same goals even when they have conflicting agendas.”
Other signals include people not showing up for meetings, not paying attention or just not saying anything.
“One of the things I’ve seen that helps projects along is a positive environment,” Jim Johnson says. “That makes a big difference, and with a positive outlook you can do so much better.”
The need for interest applies to the customers as well as the team. As Jim Johnson puts it, “You want to see active participation, active feedback and an energized user base.” If that’s not there, then the chances of project success are poor.
Lack of communication, both formal and informal, is another early warning sign. If the stakeholders, from team members to users, aren’t talking to each other, you’ve got a problem.
Ideally, project review meetings shouldn’t contain any surprises because everyone knows—in at least a general way—what’s going on with the other parts of the project.
Lack of velocity
For Jim Johnson, and advocates of agile project management in general, “velocity” is a key concept. That usually translates into a lot of small deliverables at frequent intervals. Velocity not only makes tracking progress easier, but it’s also good psychology; it reinforces a feeling of success and builds team morale.
“With IT projects, it’s difficult to operate over a long period of time,” observes AtTask’s Scott Johnson. “You need the frequent small rewards of hitting smaller milestones. If you can plan them around things you can put in your customers’ hands, that’s even better.”
“You want to have fast-moving items,” says Jim Johnson. “You want velocity of deliverables. That’s the real key.”
“One of the classic signs a project is in trouble is that things aren’t moving,” he adds.
A “No-Bad-News” Environment
“This is a really tricky cultural thing,” says Raj Kapur, executive vice president of the Center for Project Management, a software project management consultancy and education firm in San Ramon, Calif. “Everyone is allergic to bad news.” As a result, it’s all too easy to develop a culture where bad news is slow to percolate upward—which deprives management of vital, if unpleasant, information.
“You have to provide an environment where bad news is accepted,” says Kapur. “That’s critical, and it’s not the job of the team members. It’s the job of the leader.” And by extension, the CIO. Concrete Signs
All the early warning signs are not intangible. Some of them are very tangible indeed—if you know where to look.
Kapur advocates using a dashboard tool that allows managers and others visibility into a project at the click of a mouse. “Organizations that do a good job of providing an executive visibility tend to have less troubled projects,” he says. “It prevents the green-green-green—and at the last minute red syndrome.”
Lots of overtime
One early sign a project is slipping its schedule is teams working a lot of overtime. This is a particularly important indicator because assigning or encouraging overtime is the fastest fix the project manager has, as well as the one that attracts the least attention.
Generally speaking, a project running according to schedule should have little or no overtime. In fact, Standish Group’s Jim Johnson points out that the agile development process positively discourages overtime.
And as AtTask’s Scott Johnson jokingly observes, “One sign the project is in trouble is that employee health goes down for everyone on the project.” It’s the result, he says, of too much overtime leading to too much caffeine, too many late nights and too much junk food.
Diversion of resources
Another sign of trouble is having resources, usually people, pulled off the project to work on something else. This can be anything from a panic response to another project gone sour to simple bits of “oh-by-the-way” work.
The problem is that, if you’ve budgeted your project properly, these diversions are cumulative. A few hours stolen here and there don’t seem like much, but they can quickly add up. “That’s going to cascade down to the things [the project team] is supposed to be doing,” Scott Johnson warns. As a result, it’s important to keep precise track of the people and money being shuffled to other projects.
Ratios are a standard financial management metric, but they are only beginning to appear in IT project management. According to Scott Johnson, a couple of key metrics for project management are the cost ratio and schedule ratio.
@Task software includes ratios that compare the budgeted time and money versus the time and money actually spent. “They allow you to show in a ratio where you should have been on cost and schedule versus where you are running to date,” he says. “In a two-year project, you can know by week two that something is eating up costs or labor. It lets you know where you are versus where you think you should have been.”
Metrics in general are vital to keeping projects on course. “In the absence of [clear metrics] you’re relying on communication from project managers and others,” warns Kapur. “That gets you in trouble because you tend to find out late that there’s a problem.”
Milestones aren’t met
“Small, discrete and often” are the guidelines for the milestones for a successful project.
At AtTask, Scott Johnson says, milestones are weeks apart rather than months or calendar quarters. “Bite off a small piece, get it in someone’s hands and start taking feedback,” he advises.
“Discrete” means that each milestone is unambiguously defined in measurable terms with a solid deliverable. Jim Johnson prefers the term “stepping stone” to milestone. “At the end of a stepping stone you get a concrete result; a milestone might be more nebulous.”
“Soft” milestones, such as percentage of overall completion, are notoriously troublesome because it can be hard to be sure the milestones have actually been met. Even worse are milestones based on effort expended rather than results. The classic example is measuring progress in terms of lines of code written.
Scope changes (also known as the “Microsoft Mambo”)
One common method of trying to shore up a failing project is to start changing the scope. The manager or participants may scale back or eliminate features, especially if the changes don’t involve actually canceling requirements. This generally starts with relaxing requirements (such as response time) in an effort to reduce the development effort or to keep from discarding a problem module.
Requirements changes, per se, aren’t a bad thing. In fact, they’re pretty much expected in the agile method because of the constant user feedback the process produces. Indeed, changing the requirements can be a healthy thing.
What can you do when you see these problems? See Can This Project Be Saved?
The questions are which requirements are changing and why. The answers can tell you a lot about the health of the project.
Keep in mind that these signs are exactly that: signs. They don’t mean the project has failed, or is about to fail. As AtTask’s Scott Johnson points out, every “project experiences dips and gains,” and you have to allow for them.
However, the signs may indicate the project needs closer attention from higher up the management chain. One useful rule of thumb for managers is to wait until at least two (short) review periods show problems before you do anything except watching closely.
Source: CIO.com-How to Spot a Failing Project by Rick Cook
Want to become a star project manager? Develop these characteristics that mark the cream of the crop.
The best project managers are those who consistently deliver, on time and within budget, projects that meet or exceed stakeholders’ expectations. Those project managers understand that leadership and people skills are even more important to good project management than a sound methodology and project tracking tools, says Fumi Kondo, managing director of Intellilink, a management consulting and training company that specializes in technology implementations.
“The more experienced project managers understand that if you don’t get the people side of project management, it doesn’t matter how good your methodology or your tools are,” says Kondo. “If you’re not managing your users, sponsor or stakeholders, you could deliver on budget, but you might not meet their needs, and they’ll say they’re not satisfied.”
So what soft skills are necessary to become a top-notch project manager? Kondo’s firm analyzed the skill sets of both its own best project managers and those of its clients and came up with the following six attributes.
1. They possess the gift of foresight. Good project managers are able to anticipate and head off problems that can jeopardize deadlines, budgets and user acceptance.
2. They’re organized. Organization seems like an obvious characteristic of a star project manager, but it manifests itself in a variety of ways, including in an ability to stay focused on the big picture and to prioritize competing responsibilities. “In most projects, there are so many things that have to get done that it’s hard to stay on top of everything and in control of everything,” says Kondo. “Being able to prioritize work for your team is a critical aspect of what a project manager has to do.”
3. They know how to lead. Project managers have to interact with and influence a variety of stakeholders including their project teams and project sponsors. Since many project team members don’t report directly to the project manager, the project manager has to find ways to motivate workers over whom they have no direct influence and who can make or break a project. Project managers also need to be able to inspire the confidence of stakeholders and sponsors in the event the budget or timeline needs to be renegotiated or additional resources are needed to complete the project.
4. They’re good communicators. Successful project managers effectively use e-mail, meetings and status reports to communicate their ideas, get decisions made and resolve problems, says Kondo. They also understand that they need to discuss their project in the context of whatever is most important to their audience, she adds.
5. They’re pragmatic. Sometimes project managers can be too analytical, says Kondo. “They analyze things to do death before they move ahead,” she notes, which slows progress on a project. Good project managers focus on getting work done with the resources available to them.
6. They’re empathetic. “Project managers rely on others to be successful,” says Kondo. She adds that project managers can’t effectively influence others if they don’t understand what motivates their stakeholders. They need to learn stakeholders’ concerns about a project, take those concerns seriously and address them.