“We sought a regional firm who could act as our go-to partner for helping us with IT service development, budgeting, governance, project management, and outsourcing,” said Ballard Spahr Chief Technology Officer Kim Wismer. “IT Evolution’s consultants have deep experience in these areas, and they have an excellent record for helping small and mid-sized organizations like ours.”

IT Evolution CEO Scott Kushner said, “Like most mid-sized companies, law firms share the same goal of positioning IT as a contributor and enabler of a company’s performance. Ballard Spahr is an excellent fit for IT Evolution’s mix of experience and innovation in IT management.”

Ballard Spahr has approximately 475 lawyers in twelve offices nationwide. The firm’s major areas of practice litigation, mergers and acquisitions, corporate and securities, public finance, real estate, and intellectual property, including labor and employment, environmental, energy and white collar defense.

About IT Evolution

Serving the Philadelphia region for more than 15 years, IT Evolution, based in the Rutgers Business Center in Camden, New Jersey, provides IT advisory services, data management, program management and infrastructure services and support. The firm’s IT services encompass strategy and alignment, financial management and cost controls, project and service management and compliance and controls. By providing executives with clarity and consistency in IT, the company’s clients have the time and certainty to focus on their core businesses. For more information, visit IT Evolution’s website at http://itevcorp.com, or call toll-free at 888-464-1845.

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.

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.

Hopeworks enhances the lives ­of inner-city Camden youth by expanding their learning opportunities through technology training in state-of-the art computer applications: website design, geographic information services (GIS), computer networking and repair, and video.

To support the setup of the C.R.I.B. facility, IT Evolution contributed the design of the C.R.I.B facility wireless network and the planned integration of the C.R.I.B environment with the network and services available in the Homeworks main office next door. A multi-zone audio/video solution design was also developed to enable the C.R.I.B to utilize and distribute content from a single source to multiple rooms in the new building.

For more information about Hopeworks programs and business services, please visit them at http://www.hopeworks.org.

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.

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

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.

The business definition of the term is fully defined and explained in the book IT Savvy: What Top Executives Must Know to Go from Pain to Gain by Peter Weill and Jeanne W. Ross. As Weill and Ross explain in the book, being “IT Savvy refers to the planned, ongoing use of a set of interlocking business practices and competencies that  collectively derive superior value from IT investments”.

For most hard core technologists this definition will seem a little too vague and consultant-ese to really apply to the day to day wok in IT but Weill and Ross go into much more detail on their definition and provide a practical framework in which to think about IT and its support of a business.

Weill and Ross go on to further highlight five characteristics of an “IT Savvy” company:

1. IT for Internal and External Communication – Intensity of electronic communications media such as e-mail, intranets, and wireless devices for internal and external communications and work practices.
2. Internet Use - Internet based architectures (i.e. open) for key functions like sales force management, employee performance measurements, training and post-sales customer support.
3. Digital Transactions – High percentage of digitized transaction executed with both suppliers and customers.
4. Company-wide IT Skills - Technical and business skills of IT people, IT skills of business people and ability to hire skilled IT people.
5. Management Involvement – The degree of senior management commitment to IT projects and the degree of business unit involvement in IT decisions.

Weill and Ross also layout some well defined categories of IT investments and conclude that the most IT Savvy companies are investing more in the Strategic and Informational areas of IT than their competition.

1. Strategic - used to gain competitive advantage by supporting entry into new markets or by helping to develop new products services or business processes.
2. Informational - provide information for purposes such as accounting, reporting, compliance, communication, or analysis
3. Transactional – investments that are primarily used to cut costs or increase the throughput for the same cost.
4. Infrastructure - shared IT service s used by multiple applications (servers, networks, laptops, customer databases,)

Considering these high-level attributes would you consider your organization IT savvy?

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.

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

What you may not be aware of is that Outlook isn’t limited to single column sorting. To create a secondary sort, first create the primary sort by clicking the header of the principal column. Then, hold down the [Shift] key and click the header in the column that will be the secondary sort criteria. This can be used to easily locate e-mail without utilizing the search function: for example, a secondary sort based on Subject or Size within a primary sort by “To” can greatly simplify locating a specific e-mail, particularly from a Sender with whom you frequently correspond.

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.

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.

Well, according to a study by Bain & Company covered in MIT Sloan Management Review titled “Avoiding the Alignment Trap in Information Technology”, alignment may not be the largest problem in an underperforming IT organization and it may not be the first place to look for answers or make adjustments. The study suggests that the first place to investigate is the effectiveness of the IT organization. Are projects being accomplished on time and on budget? Are the systems used today running smoothly? Is there unnecessary complication in applications and infrastructure? Richard F. Connell, CIO of Selective Insurance Group, said in the article, “Aligning a poorly performing IT organization to the right business objectives still won’t get the objective accomplished.”

Additionally, the study presented some very interesting numbers and drew some interesting conclusions about the correlations between the overall performance of a business and the effectiveness and alignment of its IT organization.  As you may have guessed, the companies where the IT organizations were both effective and aligned were the most prosperous.

How would you rate your company’s IT effectiveness and its alignment to the business?

You can also view the full article in the MIT Sloan Management Review (subscription required for access to full article).