Author Archive

Ballard Spahr LLP, a national law firm with offices in 12 cities, has engaged IT Evolution, Inc. to provide IT management and advisory services.

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

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

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.

For many IT organizations, setting up a Project Management Office (PMO) is a lot like a New Year’s resolution: The best intentions don’t change anything unless you know the whole scope of what needs to be changed. In most cases, the organization knows that it needs to improve its project management, but it’s not sure what the first steps should be.

When we work with IT organizations to enhance the effectiveness of their project and portfolio management, we start by assessing where they are now: What are the needs, perceived weaknesses, challenges, opportunities, and anticipated benefits? After building a team to focus on PM effectiveness, we start our work by conducting a survey of the team to gather current impressions about how project management is handled now. Conducting the survey at both the beginning and end of a PMO development effort provides a yardstick for measuring specific improvements later on.

We’ve posted a copy of one version of our Project Management Effectiveness Survey on our Resources page. It’s available free to registered visitors. Of course, we encourage you to register for access to our entire library of white papers, technical articles, tools, tips, and other documents available free on our Resources page.

If you’d like to talk with us further about our project and portfolio management services, send us a note on our Contact Us page.

A good article appeared late last year at CIO.com about the linkage between project success and a project’s alignment with business strategy. In essence, the project manager needs to both 1) know the company’s high-level business strategy, and 2) know his/her project’s value relative to that strategy.

Many factors influence project success and failure, including schedules, resources and funding. But new project management research from training company Insights Learning and Development, certain chapters of the Project Management Institute and a strategic execution consultant suggests that the single most important factor influencing project success is the project’s link to the organization’s business strategy and the project manager’s understanding of how the project supports the business strategy.

This certainly conforms to our experience with a wide range of IT projects at IT Evolution. Every IT project should demonstrate its full business value before it even gets launched. Part of the value equation involves a solid knowledge of the organization’s strategy on the part of a project’s PM, sponsors, and stakeholders. Sometimes, the PM needs to act as the evangelist on business strategy to those who might not be as familiar with it, particularly in technical environments. Clear alignment with business strategy raises a project’s profile, solidifies its support, and significantly enhances its chances for success.

Read the full article over at CIO.com.