Project Management

Successful project implementation is the result of having the right project processes, tools and organization. If the project setup has been done correctly (see our recent post on project setup), then any issues that arise during implementation should be relatively easy to correct.

Key project processes usually revolve around status reporting, so project managers can determine if a project is on track. The status meetings will typically be at two levels: one internal within the project, likely held weekly, and one summary meeting at the executive level held monthly.

The internal meeting should focus on whether the milestones identified in the project plan are being hit, whether the right resources are being made available (critical for part-time resources) and whether there are any new requirements (scope changes) that need to be addressed. The executive summary meeting will typically focus on high-level milestones, such as business risks and especially cost projections. If the correct project setup has been completed, both status reports can generally be concise “red light, green light” documents rather than lengthy descriptions.

The project tools will usually include a tool to capture task status and display in the form of a Gantt chart. To keep these tools up to date during implementation requires some level of discipline. If they are used for resource tracking as well as schedule tracking, they require time capture by the project team, which is typically a tough culture change for mid-size organizations. At a minimum, it is recommended that the task status be reflected using simple 0% (not started), 50% (started) or 100% (completed) choices.

For the project organization, the critical aspect is identifying the business responsibility of any strategically important project. It’s very common for an organization to appoint a project manager from the IT department but leave the business responsibility fuzzy. Ideally there is a joint responsibility between IT and the business, with the key players including the success of the project on their performance evaluations.

For any project, the first step towards success is recognizing that it needs to be planned out. The goal of this early phase is to ensure that all parties have a common set of expectations for the project and that the appropriate resources have been allocated. It’s very tempting to jump straight into implementation once a new technology has been identified that could benefit the company, but the risk of some failure during execution is high in this case. It’s completely appropriate to run a brief trial or pilot phase to test out assumptions, but it should be very clear from the outset that this does not represent the final rollout.

The first priority is to get an agreement between the affected business departments and IT on the goals of the project, and to set expectations on what can realistically be achieved. This is challenging in two dimensions. First, it’s common for the IT department to have trouble communicating in a way where the business really understands IT’s intentions. Technical jargon frequently gets in the way. Second, it’s easy to underestimate how much effort is required if a business process will change as a result of an IT project, especially if the process touches external customers. It’s a common assumption that implementing a particular software package will automatically result in some kind of best practice, but this typically isn’t the case.

The second priority is to hammer out the scope of the project in detail. It’s easy to miss this step in the rush to get into design decisions, but this is where cost control starts. Many cost overruns result from scope creep, small additions to the project made without explicit authorization until the project ends up being much bigger than originally budgeted.

The third priority is to build an implementation plan. At a task level, IT projects are notoriously difficult to model because tasks typically don’t have concrete dependencies the way that, say, construction projects do.  In IT projects, typically tasks have a finish-finish type dependency (i.e. one task can’t complete before another task has completed), rather than a start-finish dependency. The happiest medium is to at least try to define tasks so that each task is approximately two person-weeks of labor. Much more than this and tasks become hard to track. The resource plan is arguably the most important part of the plan. The timeline will be meaningless unless internal resource requirements are understood.

One final thought on project setup and planning: It should be part of a company’s culture that it is okay to cut or postpone a project at this stage. If the planning shows that the risk is too high or the resource requirements too burdensome, this is the cheapest time to cut the project. If projects are regularly cut during implementation it is a symptom of incomplete project planning.

Next step: See our post about ensuring a successful project implementation through the right processes, tools, and organization.

Projects have problems. No project is trouble-free. This is one of the biggest reasons that we need project management to begin with. But too often, project teams lack the discipline to efficiently manage problems through basic issue management. The results include late-breaking surprises, missed expectations, and larger consequences to problems that could have been solved earlier with less impact.

Cataloging issues and applying a standard resolution process can immunize a project against the unexpected. It doesn’t have to get complicated. For smaller projects, use a spreadsheet; for larger projects, a database-driven solution (like this issue management template for Microsoft Access) is often more appropriate.

At its most basic, issue management requires the collection and reporting of these elements:

• A brief issue “title” or subject.
• A unique issue ID (to make it easier to reference the issue).
• The date the issue was recorded.
• A clear description of the issue.
• An issue status (“Open,” “Resolved,” “Deferred,” etc.).
• The name of the issue originator.
• The name of the issue resolver (the person accountable for getting the issue resolved)
• A list of next actions.

Why do issues need to be actively managed?

1. To drive resolution through accountable delegation. Put somebody in charge of resolving an issue to make sure it’s addressed and not lost in the everyday buzz.
2. To inform stakeholders about emerging factors that could change schedule, cost, and resources. Nobody wants surprises, and project teams don’t want to be second-guessed when stakeholders question a missed deadline or changed deliverable.
3. To speed up resolution. Protect the project from delays by keeping the troubleshooting and resolution engine running well.
4. To neutralize the impact of problems before they become much larger in scope and much harder to resolve. Like many problems in life, project problems are usually much easier to solve earlier than later. Like highway potholes, unhandled issues tend to grow in scale and impact.

Perhaps the most important part of issue management is reporting. Gathering information about issues won’t help much if it stays hidden. Issue resolution is part of project progress, and should be communicated along with the regular updates about spend, task completion, and milestones. At a minimum, the project team needs to know what issues have arisen and which remain open, but it’s even better to make sure the key stakeholders know the number and severity of issues in case they need to be called in to help.

A side note: Issue management is not the same as bug tracking. For product development and implementation projects, bug tracking is the handling of defects that become visible through formal or informal testing. Bugs are certainly issues, but obviously not all issues are bugs, especially if the project doesn’t involve software development or implementation. It’s up to the project manager to determine how much the two processes overlap, and whether one or two different kinds of processes and systems are needed to manage them.

I have always felt that the one essential trait that lifts a business analyst above the level of pure methodology is curiosity. To get good requirements, you need to be very curious about your topics. I’m glad to see my belief echoed in a good article by Kupe Kupersmith on his blog at the Business Analyst Times. In his recent post, “You Need Desire to be a Desired BA,” Kupe asserts that natural curiosity is a part of everybody’s personality, and BAs who exploit it are better at eliciting requirements:

If you have the desire you will adapt your approach over time to do what is right for the customer. You’ll question practices that are done just because that is how you or others have been doing it for years. You will become persistent in trying to find out the root cause of the business opportunity or challenge to feed your natural curiosity.

Frankly, all of life seems richer if you face it with a natural sense of wonder at how things work and what they mean. Good requirements elicitation comes not just from the initial questions we prepare for our information sources. It emerges from our follow-up, from the first answer followed by more questions to work out details, understand meanings, trace consequences and implications. As a one-time journalist, I often equate requirements-gathering to a kind of investigative reporting, where you never accept the first answer as the whole answer.

A natural curiosity also feeds itself, acting as an inspiration to continuously learn, and to not assume that what is true on one day will remain true forever.

An ERP (Enterprise Resource Planning) system can bring significant benefits to your organization. The integrated nature of the system reduces double entry of data, improves visibility of information throughout your organization and can speed up key processes.

ERP systems pose a significant challenge to implement though, especially in mid-size organizations which are not able to dedicate full time resources unlike the large multi-nationals.

Successful implementations typically have several characteristics in common:

1. Understand the business drivers for change.

It is very tempting to start an ERP selection or implementation without a complete understanding of why you are making the change. A lot of companies will have generic criteria that push them into starting a project – such as “our current system is too old”; then part way through the implementation when things are tough they kill the project because there is not a strong enough business case for going forward.

It is always worth exploring, documenting and quantifying the case for change. This will drive much of your design and help you keep costs under control. And, if you can’t quantify the benefits, there is a strong chance you won’t achieve them.

2. Keep the ownership of the change within the business, not just IT

There is a significant IT component to any ERP project. But you can’t  outsource the whole implementation to IT and expect to get the benefits. There will be some level of business change associated with any integrated system and only strong business ownership can push these changes through.

Make sure you have a steering committee that includes senior business leaders and ideally include the project objectives on their performance appraisals.

3. Understand the 80:20 rule to cost and complexity

Whenever you try to select a new system, you have to make some assessment of the level of fit to your organization and processes. Generally, once you have found a vendor with a reasonable fit for your industry, you will typically be able to describe the fit as somewhere near to 80%. At that point, a lot of companies make a general statement such as “we will change the process to fit the software” or “we will pay for the customization that we need” and then move on.

Take the time to understand in depth that missing 20%. It will be very easy for that 20% to end up driving 80% of your effort, angst and costs during implementation. It is particularly true of any process which touches your customer.

4. Define up-front the selection criteria for a vendor

It is important to understand the functional fit of any one particular software package. But once you are down to a short list of 2-3 vendors, functional fit may no longer be the key deciding factor in settling on one favorite vendor. Other key factors will include level of support and training; availability of user groups; technical architecture; attitudes to customization and financial stability of the vendors.

Take the time at the start of the project to define the key factors for your organization and their relative importance – don’t wait until you are already through all the demos. These factors can help you get to a short list quickly and make your selection process much more efficient.

5. Ensure strong project and vendor management

Many organizations don’t have the skills or capacity to focus on the project and vendor management that is necessary to shepherd a successful implementation. Any vendor will provide some level of project management, but those resources are only focused on the tasks that the vendor will perform.

You need to make sure that there is someone focused on advocating for your organization in project meetings with the vendor and also managing the resources internal to your organization. Make the investment to get this help externally if necessary.

6. Develop a strong scope management process before and after implementation

Finally, we have all heard about the runaway projects which either get cancelled or implemented late or way over budget. A critical factor in keeping things on track is to keep a tight rein on scope. Once you understand more about what any software package can do it will be very tempting to keep adding new processes and reports into the project scope until one day you realize that you have a much bigger project than you originally defined.

Hold tight to the business case that you developed at the start of the project – only include those items which drive the business benefits that you are striving for. Everything else can wait until later – and then needs to go through its own justification.

Big failures can result from the best intentions. The IT product selection process is a good example. Some of the biggest mistakes in the growth of a company’s technology infrastructure occur during inadequate solution selection processes, including those that use Requests for Proposal (RFP) and competitive bidding.

We just published a major white paper – “Avoiding the Product Selection Quagmire” – that details what can go wrong with IT product selection efforts. It also describes what should be done to overcome risks and run a top-notch RFP or competitive bidding project.

In small to mid-sized companies, IT teams often get caught off guard by the unanticipated demands of the product selection process. Although competitive bidding is a well-known best practice, many organizations lack the practical experience or the tools to execute a selection process effectively. Companies who find themselves reinventing the wheel with each product selection project will likely encounter any of a number of risks:

• A lack of expertise and experience in the full competitive bidding and product selection process.
• Failure to set up product selection as a formal project.
• Inadequate handling of requirements.
• A lack of balance between business and technical emphasis.

When these pitfalls occur, the company could end up making a buying decision for a solution that won’t be adopted, isn’t aligned with the real requirements, or costs much more than a better solution.

Here are the white paper’s key recommendations:

1. Set up each product selection effort as a formal project.
2. Augment your internal expertise as needed: Partner early on with a provider of talent with experience conducting product selection projects.
3. Engage an internal or external business analyst to gather and document requirements.
4. Leverage existing tools and methodology to execute the selection project.
5. Foster a good partnership between business and IT throughout the project.
6. Choose the appropriate type of competitive bidding request, one that best suits the project objectives.
7. Adopt a component-based, reusable RFP format and structure.
8. Adopt a standard, reusable timeline for the bidding and selection process.
9. Conduct the selection using a complete decision package.
10. Prepare early for the transition to implementation.

The paper explains each of these recommendations in detail, giving IT practitioners a practical set of steps for reducing product selection risk and raising IT’s profile as a key contributor to business success through quality technology purchases.

The white paper “Avoiding the Product Selection Quagmire” is available free on our Resources page to all registered visitors to our site. Registration is free and gives you access to all of our other free white papers, articles, templates, and work samples.

At the end of a project, after the team is done with the long hours and occasionally short tempers, it’s a challenge to focus on that last project phase: Closing. Team members start to focus on other activities, and it’s often left up to the project manager to play the final act as a solo, archiving the project materials and tying up loose administrivia.

But project closure provides one of the best opportunities for improving your overall project execution. It’s the time when completed objectives can be compared to original intentions, when a team can scrutinize its methods and processes to determine what worked and what didn’t. The team activities of project closure – the “lessons learned” meeting, the closing report, etc. – provide one of the only opportunities for retrospection amid the busy operation of a full portfolio.

One of the best ways to learn about the effectiveness of a project’s management is to evaluate the project through a survey of team members and stakeholders. A written survey helps guide reflection, spark recollection, and focus on key points of execution that require the most vigilance in maintaining project excellence. Surveys collected over a number of projects provide valuable historical insight into the effectiveness of particular methods, and help guide decisions about adapting your PM methods to your organization’s unique circumstances.

In our Resources section on this site, we’ve posted an example of our IT Evolution project evaluation survey form for our registered visitors. It’s built from a number of sources combined with themes from our own experience. Feel free to download and use the survey for your own projects, and start building a history of your successes and improvements.

(If you haven’t registered yet, you can sign up using the “Registration” link on the upper left of the Resources page.)

I’ve been a “firefly” Twitter user for a while, meaning that I’m on and off about Twitter from time to time. I think that at least the concept of the platform has meaning for project managers and team leads because of the crucial impact of communications on project success. I’m just not sure that the best implementation of the concept has appeared yet.

In the meantime, Toby Elwin at the Project Management Hut has put together a useful compendium of Twitter knowledge for project managers that goes beyond what novices need to know. He’s clearly an enthusiastic advocate of using Twitter as a project communications tool:

You have an obligation to communicate, but with Twitter you now have an opportunity to communicate more efficiently, more effectively. 4 reasons to use Twitter for project management:

• Concise messages
• Topics filtered by keyword (more on this below)
• Link to documents or websites
• Track communications by user and using a time stamp

I wish he contributed a few more words to how Twitter – or microblogging in general – should fit into an overall project communications approach. Some kinds of project communication are easily adapted for Twitter, while many are not. I’m also skeptical about Twitter’s effectiveness as a project tool simply from the perspective of user adoption. For Twitter to be effective in this context, all of the project team has to develop the Twitter “habit,” which means making Twitter and tweeting as much a part of your electronic communications activity as e-mail and web browsing. That takes time, and people new to Twitter don’t often grasp where its value lies. Twitter for projects works best in environments where the team members have already drunk the Twitter kool-aid.

All the same, Elwin’s post provides helpful tips and lists of tools that can direct an early explorer of the Twitterverse to a better knowledge of the platform.

I’d love to hear from anyone who has experienced Twitter – or its more corporate-friendly cousin, Yammer – in a project context.

We are way too addicted to e-mail.

Project managers in IT often confront the tall hurdle of fostering smooth communication among team members separated by time and distance. It’s not easy. The IT project highway is strewn with failed and discarded projects that spun out from poor communications across widely distributed teams.

The challenge for a project manager is to develop for distributed teams a sense of presence that leverages new technologies with appropriate usage. Presence is one aspect – perhaps the biggest – of a team member’s engagement with the project team and its coordinated activity. Although e-mail supports an existing sense of presence, it is incapable of creating a sense of presence on its own.

Think of what “presence” means relative to the physical placement of a team of people working together toward a common goal. The best sense of presence exists in a team where the members are in the same place at the same time interacting face to face (e.g., a football team or a focus group). Close behind is the team that’s under one roof but in different locations (think cubicles). Then there’s the team where the members are in different buildings but the same postal code. The physical separation of teams can extend across multiple states, countries, and continents.

Contrary to what telephone ads say, long distance is simply not the next best thing to being there. To be successful, we need as much team presence as we can achieve, but we can’t achieve much when we’re so geographically separated. Well, presence is all about communication. If we look at the spectrum of presence in the team examples above, most person-to-person communication generally falls into two categories: synchronous and asychronous.

Synchronous communication occurs when people interact in a real-time dialogue. The obvious example is two people in the same room talking to each other. Direct telephone conversations are synchronous (although phone tag via voice mail is asychronous). Instant messaging (IM) and chat are synchronous, but with intriguing potential for latency (such as sending an instant message to somebody who gets it an hour later). Through high-tech telephony (e.g., Voice Over IP (VoIP)), IM, and chat, we’re experiencing new and diverse ways of increasing the information stream through the combination of visual and aural channels. Video-enhanced IM is an example of this, and so is the IM window that displays what songs you’re currently listening to while you’re chatting with somebody about your latest status report.

Asychronous communication, on the other hand, operates in bursts of one-sided dialogue. The most obvious example is e-mail. When I write you an e-mail message, I send it without knowing when you’ll read it or when (or if) you’ll respond to it. I generate it on my own time and terms, and you respond on your time and terms. This is good in a world in which we’re not all on the same schedule. Messages can be queued up, and the act of responding can be queued up as well. Before e-mail, the written memo was the primary example of communication asynchronicity. Another example of asychronized dialogue is the blog, which has the added backbeat of e-mail as well as blog comments to augment the layers of communication. Twitter and its corporate-friendly cousin Yammer are kind of a mash-up of IM, blogging, and e-mail.

Both synchronous and asychronous communications provide the means for people to be present to each other in varying degrees. Assuming we have all of these diverse, cool ways to communicate, what helps a team the most as it strives for its goal?

To me, it seems to come down to two things: bandwidth, and what I’ll call (for lack of a better term) appropriate messaging.

For this discussion, bandwidth refers to the potential range of information that can be communicated in the context of a particular exchange. Two people talking in person, face to face, is high-bandwidth communication. In addition to the actual words, each communicator can also parse intonation, facial expression, body language, and some of the more subtle signals (personal appearance, etc.). A two-way videoconference is high-bandwidth (although not as much as in-person) because it combines visual and aural richness. A telephone conversation is the next step down in bandwidth, eliminating the visual and some of the detail in the aural spectrum. (With cellphones, bandwidth shrinks even more because of the “Can-you-hear-me-now?” syndrome.)

Asynchronous communications generally have less bandwidth than synchronous, but not always. A video-mail message has greater bandwidth than a conventional e-mail message. But it has less bandwidth than a videoconference because the latter is synchronous and real-time, incorporating the immediate responses of all participants to the messages being conveyed. For all the ubiquity of e-mail in our working world, it surprises me how much people ignore the low-bandwidth nature of that means of communication. Without quirky visual add-ons like emoticons and “grin-dicators,” e-mail cannot convey emotion very well, or any of the other nuances that come through the visual and auditory aspects of higher-bandwidth exchanges. Nearly everybody has had at least one bad experience with misinterpreted humor in e-mail, and we all know the principle that major bad news should not be conveyed through e-mail.

Yet distributed work teams often rely heavily on e-mail as the medium of choice for most communications. Because of e-mail’s inherently limited bandwidth, this can mean real problems in overcoming the challenges of being physically distant. Without augmenting presence with other communication channels — in-person meetings, Twitter/Yammer, phone calls, IM, videoconferencing, etc. — a team can run amok in response to misfires, omissions, and the other slings and arrows of a limited medium.

However, the asychronous nature of e-mail is its saving grace. There are plenty of communications where e-mail is the best medium for the message. And that’s what I mean by “appropriate messaging”: Pick the right means for what you need to communicate.

• To exchange a lot of information in a short time, get everybody in the same room. (Get rid of the chairs beforehand if you want to keep the meeting short.)
• To ask a quick question, use IM or the pick up the phone. (It’s best to batch up your questions if you risk repeatedly interrupting somebody’s work.)
• To engage in a one-on-one dialogue with a geographically separate colleague, crank up the webcams to allow facial expressions and body language to increase the level of engagement.
• To make a specific statement for which an archival record is required (e.g., meeting minutes, meeting agenda), use e-mail.
• To conduct brief written dialogues with the whole team in order to convey status, progress, questions, issues, etc., check out Yammer, the internal microblogging platform that has grown increasingly popular in IT environments.

The presence to each other of distributed team members is enhanced less by the increase in the means of communication and more by the specific means they choose for conveying their messages. While it’s probably best to have the most high-bandwidth exchanges you can afford, it doesn’t mean lower-bandwidth communications aren’t useful as well.

Tough times in midmarket companies have compelled IT managers and employees to wear more hats (and bigger hats, too). Whether through staff reductions or withdrawal from outsourcing arrangements, IT teams in the “Great Recession” have had to do more with fewer people. This means that “generalists” – people with multiple skills and know-how across a number of IT knowledge areas – are more likely to keep their jobs and even thrive in them, or get the new job if they’re in the market.

This is the message confirmed by the IT salary survey conducted last month by SearchCIO-Midmarket.com. In addition to the survey results themselves, comments in the article by several IT managers confirm that generalists are in demand:

“‘Specialists are in big trouble, in my opinion,’ [according to Bob Clabaugh, director of network and systems engineering at Northwest Regional Education Service District in Hillsboro, Ore.] ‘Broad-skilled generalists who have had their hand in everything are going to be the ones scooped up by midmarket IT shops.’ Smaller organizations will be looking to fill multiple roles with one person, saving on employee onboarding costs and multiple salaries.”

In our work with many midmarket companies in the mid-Atlantic region, we’ve spoken with many CIO’s who express a need for IT practitioners who demonstrate knowledge of and interest in the business side, who regard IT as the enabler of business performance, directly or indirectly. Often, when an organization lacks such generalists internally, outside help is often needed to both provide a broader perspective, and to coach the organization to develop that talent internally.

Visit the the IT salary survey at SearchCIO-Midmarket.com for the full article.