Three ways to minimize your project budget exposure

Date: November 19th, 2010
Author: Brad Egeland

Keeping the project budget in line is one of the most difficult things that a project manager does — and yet it's a huge factor in determining the overall success of the project when the engagement winds down. The goal is to keep the budget in line throughout the project and avoid falling into emergency mode at any point with a huge overrun.

The three processes I'll talk about here are extremely helpful to me as I try to keep my project budgets in check. Developing good processes and habits will help you significantly reduce the likelihood that your project budget will turn into a catastrophe. Let's review each of the three ways that will help you minimize your project budget exposure.
Review and revise the project budget at least weekly

The first thing you can do to protect your project budget is probably the easiest thing you can do, and it's definitely the least invasive thing you can do. Get weekly information from Accounting concerning the charges to your project and revise your information diligently every week. This may seem simple, even mundane. But it always amazes me how many project managers get lazy and let this slide for a week or two and then, eventually, longer. "Hey, it wasn't a problem three weeks ago and nothing significant has happened on the project, so why should my budget be in jeopardy now?"

Well, little things build up — and they can build up fast. Stay on top of the budget; don't let a week go by without comparing forecasts to actuals and reforecasting, if necessary. It's much easier to fix a 10% budget overrun now before it gets out of control than it is to fix a 40% budget overrun a month from now after it's already out of control. And which one is management going to be more pleased about hearing? Which one will the customer be more understanding of and more flexible about?
Make your project budget high profile

This is also a fairly easy process and has worked well for me. If your organization is a matrix organization with everyone working on multiple projects at once, it works even better. Here's the scenario:

You are a project manager running five projects at once. On average, each of your technical team members are on three different projects at the same time. In all honesty, 80%-90% of all employees calculate their project charges for the week at the last minute, usually on Friday. Very few accurately document their time during or at the end of each workday.

We all remember most of what we did in a particular week, but there are always those four or five hours of activity that we really can't pinpoint. We know we worked 50 hours that week, but can accurately account for only 45 of them. Those hours have to go somewhere, but where? They go to the project where they'll be least noticed–the project that we know is not being monitored closely.

So don't let that be your project. Make sure your team members know you're watching your project budget — and the hours that they charge to it — like a hawk. Discuss the budget with them at every weekly internal team meeting and give them a status update on how the project budget is standing up to the original forecast. Share your concerns with them. Periodically question them on charges just to keep them on their toes. Don't be accusing, just ask them questions about the charges and the work that was being performed. If they know you're that aware, it's highly unlikely that any of your projects will be recipients of the "gray" hours at the end of each work week.
Manage scope closely

This is probably the hardest one to do and can have the most devastating affect on the project budget. The problem here can be two-fold. You have the issue of managing the project scope from your project manager perspective and negotiating changes and change orders with the customer. But you also have the task of managing your project team members closely as they work with the customer.

On at least a third of my projects I've run across potential scope issues through discussions I've had with my project team members who were in close communication with the customer. Those team members develop a relationship with the customer, which results in their agreeing to any small request the customer makes. This "small" request ends up costing your developer a few hours (which can mean a few thousand dollars) of your precious project budget.

Inform your team members, warn them of these kinds of situations, and then, when you meet with them every week, ask them about any customer requests that may have been made in the interim.

How to market your internal IT department

Date: November 22nd, 2010
Author: Patrick Gray

Marketing their organization is something most CIOs spend little time considering. While no one likes a shameless promoter, many of the most successful IT organizations I have worked for actively market themselves around the corporation, even if they may not use the term "marketing" to describe their activities. Without some element of marketing, IT will often be neither seen nor heard, unless summoned, save for the rumor-mill rehashing of its most recent stumble or failure. With some simple marketing efforts, the company as a whole can be reminded of the services IT can offer, informed of recent successes, and be seen as a home to thought leadership on technology. Here are a few simple ways to market your internal IT organization with little to no marketing budget and a minimal investment of time.
Change your attitude

The most effective leaders in any organization are those who can sell their vision. While it may seem crass to call every great leader an effective salesperson, it is largely true. Effective leaders can pitch their point, expound on the benefits that are most likely to appeal to the current listener, and then "close the deal" with the support of much of the organization.

This "sales" attitude permeates everything from management presentations, to structuring organizational efforts that appeal directly to potential "customers." IT especially is a group that peddles ideas, and considering every interaction with other business units as a chance to pitch your most compelling ideas can do wonders for how you structure a proposal and present its benefits. While something like enterprise software might affect the whole organization, a change in attitude will cause you to present the package differently to operations than you might to finance and will cause you to have laser-like focus on appealing to the listener's interests, rather than self-centered technical discussions or questionable and unconvincing "benefits."
Drop the jargon

The most effective marketing reaches us in a language we can easily understand. The same product description will use different language and imagery when targeted at one group versus another, but in each case will appeal to those groups in their own terms. While we in IT may get excited by talk of virtualized cloud services and ITIL frameworks, the people impacted by these technologies usually care less about the fancy verbal footwork and simply want to know how their working lives will be improved by what we are peddling. When we can separate the benefits from the technologies that deliver them and effectively articulate those benefits, then IT will be best presented and most easily accepted and embraced.
Become a thought leader

Technology, especially in the consumer space, is changing at a record pace. Most of us have been cornered and asked for an opinion on some new gadget or technology making the press's rounds. Rather than waiting for these ad hoc "hallway moments," publish an informal newsletter that talks about some of IT's recent successes and addresses current technology trends. There's no shame in having a young staffer who is passionate about the latest mobile technology pen a couple of paragraphs about how Android could affect the company or about some apps that could help the iPad become a productivity tool. If you as CIO are not presenting this information, executives may be looking to teenage children or staffers outside IT, making corporate IT look like a dated dinosaur rather than a trend spotter.

An IT newsletter need not be an overwrought, ten-page affair with marvelous graphics. It can start as a simple four or five paragraphs that are e-mailed to a handful of colleagues. The best are informal and informational that address the concerns of readers. Ask a trusted colleague or two what technologies they are following and interested in learning more about. Combine this with short and subtle promotional features about IT's recent successes, and you have a winning formula that presents IT as competent and knowledgeable. Old-fashioned e-mail is usually a better tool than a blog buried on an internal Web site that few will read, and if you are comfortable with it, self-effacing humor and an informal style will gain more readers than a staid yawner that reads like a master's thesis.

While marketing is probably one of the last things you thought you would need to worry about as an IT executive, any organization, whether it is a Fortune 100 company or an IT department of five people at a small company, can benefit from being presented in the best possible light. Dedicating four or five hours each month to these activities can build trust in the IT department, improve its image, and even make the next budget-approval process far less painful.

Five tips for teaching database concepts to clueless users

Author: Susan Harkins

Investing a little time in helping your users understand database fundamentals will make them more productive and self-reliant. Their understanding and insights may even help you improve your applications.

If you're managing or developing custom applications, chances are you have a few users updating at least one database. These users need to know how to interact with the database, but they don't need to understand what's going on behind all those forms, right? Actually, a little knowledge in concepts could lead to improvements in performance, efficiency, and even value-added features that often, only the users down in the trenches can fully appreciate. A basic understanding of database concepts can help otherwise-clueless users offer innovative suggestions and even point out potential hotspots before they turn into real problems.
1: Hire someone with an expertise in teaching beginners

You might have been the professor's favorite student, but that doesn't mean you're a good teacher. Teaching database concepts to most users isn't for the faint of heart. Users aren't stupid. In fact, many are not only able but also quite eager to learn. You just need easy-to-understand examples and scenarios. And for better or worse, most developers and managers just don't think that way. Your would-be scholars don't care about Codd or cubes — one will bore them, the other will totally undermine their confidence! If you really think you can do it, go ahead and try, but be mindful of that deer-caught-in-headlights stare. It means they don't understand you, not that they're stupid.
2: Work with associations

It's okay to acknowledge E.F. Codd, but your goal is to introduce users to relational database theory and possibly even the SQL language. You could easily provide slides of bulleted rules and guidelines, but don't. Information provided that way won't mean much to most users. Instead, take advantage of their familiarity with other common tools, such as spreadsheets and file cabinets. You know that a spreadsheet is not a database, but a sheet is a good way to introduce rows as records, columns as fields, and sheets as tables. Compare what they already know to what they have to learn. You might think this method is old and worn out, but don't push it aside just because it's old. It's old because it works.
3: Avoid development tools while learning

You'll probably want to use an actual database while teaching concepts to run simple examples. Although you could supply a set of client management tools, don't. All you'll do is teach your students bad habits — habits that rely on a specific set of management tools rather than concepts. It's important that your students understand the basics before they learn to interact with the data via visual tools. If you want to apply examples to data, use a command-line interface. In the long run, learning how to type query requests directly will benefit them far more than learning how to use a specific set of tools. Once your students understand the concepts, then introduce them to the visual interface tools.
4: Use familiar data

Your users are already working with data that in some way relates to your business. If possible, work with simple examples that rely on that familiar data. It may not seem like much to you, but you'll eliminate time needed to introduce example data and give users a boost up the learning curve.
5: Set aside enough time for implementation and study

Your users won't retain much if they don't have an opportunity to put what they've learned into action. Assign additional time outside of classroom training for individual experimentation and further learning. Assign homework by presenting a real-world problem and give students a little lab time to find a workable solution. I realize that it might be difficult to get upper management to agree to this request, but nothing can replace hands-on experience.

Five tips for securing mobile data

Author: Shun Chen

As more and more company data moves onto mobile devices, IT faces a host of new security concerns. Here are some issues to consider as you develop your mobile security model.

More and more corporate data is being moved onto mobile devices through email and cloud-based mobile applications, so securing mobile data is becoming increasingly critical. However, traditional security models break down when it comes to mobile. Mobile devices can't be managed autonomously by IT because IT can't enforce upgrades or install applications or programs without the end users' consent. Therefore, an effective mobile security model needs to be based on visibility and mitigation, not command and control. Based on our experience working with enterprises around the world, here are five tips for securing your mobile data.
1: Ensure visibility

The request to get email on new devices such as iPhones and iPads often comes from the CEO, and IT responds by turning on ActiveSync. However, the problem is that once you've turned on ActiveSync, anyone can get onto the network. As different mobile platforms provide different capabilities for device security and control, the first step in mobile security is to find out exactly who is accessing your network and what devices they are using to do so. Then you want to be able to set access control policies that can determine whether to allow or block access based on hardware type, OS version, or compliance status. ActiveSync is a great technology to set some baseline controls, but it's important to complement it with the right tools to ensure the security of your network.
2: Make sure you can do the basics

Any mobile device management and security technology you evaluate needs to be able to handle core mobile security functions:
Remote lock and wipe
Password policy
Encryption monitoring
Jailbreak and root detection
Device restrictions, such as denying access to certain apps (e.g., password spoofers) and explicit content

Keep in mind these are the minimum requirements that should be on your checklist.
3: Create clear policies and communicate them to employees

One major decision that many enterprises are struggling with today is whether they should allow employees to use their own devices. Whether the phone is owned by the company or the employee, it's inevitable that it will end up with both corporate and personal data on it. Therefore, it's essential to actively communicate your data security policies to your employees and to make sure that the information is in a place where it can be easily found. You will need to make decisions about two big areas. The first is how you handle personal versus corporate data — for example, what gets stored or archived on company servers, such as SMS? What gets wiped or removed if an employee violates policies? The second area of concern is privacy and who sees what. Regardless of your policy, the most critical factor to consider is transparency. It should be easy for an employee to find your corporate data security and privacy policies. They should know exactly what IT tracks, monitors, and archives. Then they can make decisions about their own device usage.
4: Make sure you're securing everything — not just email

Mobile security is no longer just about email. Through the use of mobile apps, more and more company data is moving onto mobile devices, so you need to have visibility into apps, as well. You must have a central view of all the apps employees are using, and you need to be able to blacklist apps that pose a threat to security or compliance.
5: Stay flexible

It's important to remember that enterprise mobility is really new. Be prepared to evolve because everything will keep changing. New OS releases will have new features and functionality. New devices are going to keep coming (consider  the iPad-led tablet computing wave), and there will be more mobile apps and data to secure. You need to be alert to all of these developments because many will have implications for the policies you've established. The most important thing is to maintain complete visibility into your mobile environment and regularly evaluate your security policies to make sure they align with your mobile reality.

Shun Chen is director of product management for MobileIron.

Five tips for designing a small business network

Author: Brien Posey

When you design a network for a small business, you have to address different issues from those you face in an enterprise environment. Brien Posey offers some tips for handling the special considerations that come with the SMB territory.

Over the years, I have designed numerous networks for various organizations. In doing so, one thing I have learned is that you have to use a different mindset when you are designing a small business network than you would use when developing an enterprise grade network. Here are five simple tips to keep in mind when you build a small business network.
1: Determine whether you want to host services locally or in the cloud

I have to admit that I have never been a big fan of hosted services. Over the last year, I have received letters from several network administrators who have found themselves unemployed after the companies they worked for began outsourcing network services to cloud providers. Even so, using hosted services may be ideal for smaller organizations.

Cloud service providers take care of configuring, maintaining, and backing up network services. An organization that is using a hosted service may not need a dedicated IT staff. Hosted services may also save smaller organizations from having to make a large investment in server hardware and software. Instead, they can pay a monthly subscription fee. Over time, the subscription fees can add up to more than the cost of purchasing server hardware and software, but the startup costs are much lower.
2: Look for ways to control costs

Small businesses typically have to watch every penny, so if an organization does decide to host its own network, it's important to look for ways of controlling costs. Using server virtualization is one obvious way of reducing the costs of server hardware, but sometimes you have to get a little creative. For example, in extreme situations, you may have to settle for using high-end PCs instead of true server hardware. Likewise, you may be able to control costs by using Linux operating systems instead of Windows.
3: Have a support plan in place before you need it

Small businesses often lack the resources to deal with any major technical issues. When I have done consulting projects in the past, I have found that a lot of small businesses don't have a dedicated IT staff. They often have one employee who knows a little bit about networking and becomes the go-to person for computer problems.

I have also seen a few small businesses hire someone to provide full-time IT support. In these situations, though, budgetary limitations have prevented the organization from hiring someone with a lot of experience.

Don't get me wrong. I'm not bashing the way small businesses do things. Organizations have to work within their financial limitations. But problems will occasionally occur that are beyond the staff's abilities to fix. So organizations should have a plan in place ahead of time for how they will deal with such problems when they occur. These plans might involve calling a technical support line or bringing in a consultant. Regardless, when you build a network for a small business, be sure you take up the issue of long-term support with the company's owner.
4: Plan for future growth

When you design a small business network, remember that the business may not stay small forever. Make sure you design the network in a way that allows for growth.

I have known consultants who automatically use Microsoft's Small Business Server 2008 any time they build a network for a small business. I don't deny that Small Business Server is a good choice for some organizations, but it has a limit of 75 client access licenses. Furthermore, it does not allow for the creation of child domains or inner forest trusts. The products that make up Small Business Server are not licensed in a way that allows them to be installed on separate servers.

So while Small Business Server may be a good choice for an organization with 10 employees, an organization that already has 50 employees could end up outgrowing Small Business Server fairly quickly. It may be better for such an organization to spend a little extra money up front so that it doesn't have to pay for an expensive migration later on.
5: Never underestimate the importance of a good backup

I couldn't even begin to guess how many times I have done consulting projects for small businesses only to discover that they had no backup or that their backups were inadequate. (Running a backup every Friday night just doesn't cut it.) When you design a small business network, disaster recovery planning should be part of the design process, not an afterthought.