IT Project Management - News and Articles

What do users want?

June 26, 2006 from ComputerWorld - "Want to complete a project successfully? Then you'd better have success at the start. That means getting requirements right, and there are as many ways to do that as there are business analysts charged with getting it done.

But impatience, miscommunication, misunderstandings and overlooked users can produce requirements that aren't clear or complete. "You want to have as little ambiguity as possible, because ambiguity creates defects," says Andrew Ari Clibanoff, a senior business analyst at GSI Commerce Inc., a King of Prussia, Pa.-based provider of e-commerce services.

Those defects can be costly. Ellen Gottesdiener, principal consultant at EBG Consulting in Carmel, Ind., and author of The Software Requirements Memory Jogger (Goal QPC Inc., 2005), says that roughly one-third of the budget for a typical project goes to fixing defects that originated in faulty requirements.

The following tips will help you avoid becoming part of that depressing statistic.

Understand the overall objective. "You need to have a point of reference: What is the strategy for the organization? What are they trying to accomplish in the medium and the long term?" says Josephine Day, director of customer care and technology at the Project Management Institute in Newtown Square, Pa.

When the objective is clearly defined, you can identify the right stakeholders and users, as well as which other programs could be affected by the proposed project -- all important steps toward success, says Day."

180 View - The article goes on to give some practical advice in collecting user requirements. However we think there are huge problems with the advice. Users often don't know what they want. They know the business process and the problems, and that's what a good analyst should document. Users may also not know what's possible. As well, some users may not be forthcoming because of job security concerns. Another problem with the approach in the article is that the level of detail in requirements will vary depending on the project. If you're documenting requirements for a system that will be purchased such as an ERP system, there is no need to document the basics. For example, if you're documenting Accounts Receivable, it's a waste of time to document the requirements related to an Aged Trial Balance. All the systems have it already. It would be better to focus on requirements that differ across systems. And lastly, all requirements don't have the same priority. You need to prioritize each requirement. Only those requirements that allow companies to achieve their CSF's (Critical Success Factors - defined as those things that must be done well in order to achieve success) can be classified as critical. But we do agree with the writer's view on being unambiguous.

There’s a simple key to being a successful Project Manager: keeping updated lists of all issues

December 16, 2005 from Computing Canada - "The Project Manager’s secret for success is keeping good lists. That’s it. Earlier this year I took over a project from another project manager. He was removed from the project for failing to perform to the satisfaction of the sponsor. Before the PM exited stage left, I asked him for his project issues list. Not the list of three issues that you publish to the world in your status report, your real issue list. You know, the 25 issues you are actually managing. Turns out he didn’t actually have an issues list. His lists were found in various e-mail trails, in half-recorded phone memos and on Post-it notes that decorated his cubicle. So I sent him a template and asked him to record all his issues. Two days later a list emerged. And there you have it — project management at its worst: The PM who is not in the habit of keeping track of things.

Even average project managers keep issues lists. They have to. Issues bury mediocre PMs. They have issues because they don’t keep other lists — lists that will prevent issues. It took me several years of learning the hard way that you must keep lists. Here are a couple of essential lists to keep:
1. Charters. Your charter is a list that describes the initial position for a project. Just today I read a charter from another project. I could tell from reading the charter this project is going to be trouble. It had ambiguous scope statements, vague assumptions, no risks and the project responsibilities weren’t defined.
2. Project decisions. Decisions are made which affect your project’s ability to deliver. For example, a decision is made by some high-ranking executive to take a key resource off your project for two weeks so that person can do a special assignment for the president. Six months later no one can remember why your project slipped.
3. Issues. You are constantly resolving issues. Here is a tip: Keep your issues list open at all times. As you get an e-mail update, add it to your issues list and remove the e-mail from your inbox. Is this a lot of work? You bet it is. But it’s easier than spending 20 frantic minutes three days later sifting through your e-mail looking for that critical bit of information.
4. Communications plan. As you know we project managers feel like there are never enough hours in the day to communicate with all the people we need to. Typically, as we head towards the parking lot to get our car at the end of the day, we feel we could have communicated more. But do you keep a list of the communications you have to be making? And if so, do you look at it from time to time? A communication plan is only good if you pull it out on Friday morning and ask yourself “have I connected with everyone I was supposed to?”
If you want to determine if project managers are staying ahead of the game, ask to see their lists. They should be able to produce them instantly. And, if they don’t have good lists that they manage with, then they are likely headed towards a project disaster." The entire article was reproduced, but you can look for yourself by clicking here.

What C-Level Executives want from Project Managers

Michael Burns is chairing a presentation on what C-Level executives want to hear from Project Managers at ProjectWorld in Toronto on May 18, 2004. It's not enough to be on time, on budget and in scope. The project needs to be aligned with corporate strategy and requires a business case. Michael will present some of the theory, followed by real life experiences from Dave Codack (CEO) of iStark, Neil Baimel (CEO) of NewStep Networks and Cleo Chmielinski (CFO) of Bayshore Health Care. For more about ProjectWorld and this presentation, click here.

180 Systems is quoted in ITbusiness.ca for remarks made at ProjectWorld in April 2003

Getting projects finished on time and on budget isn't enough anymore. The project should also be aligned with corporate strategy. For the article, click here.

ProjectWorld Toronto - April 21-25, 2003

ProjectWorld is Canada's national Project Management Conference and Trade Show, and for the first time 180 Systems is participating. We are doing a session for the symposium called "The 4th dimension - It's no longer enough to be on time, on budget and in scope". As well, we are facilitating a round table discussion with the help of James Norrie, President of e-Venture Consulting, entitled "What C-Level executives want from Project Managers."  For more information about ProjectWorld, click here.

David Maister's Web Seminar on Managing a Group of Professionals

On October 16, David Maister presented the findings of his new book (First Among Equals) in a one hour web seminar hosted by Changepoint Corporation. David is a leading authority on management of professional service firms. David believes that a professional service firm's competitive advantage is the energy, drive, excitement and enthusiasm of its staff. However, managers are not hired, trained or rewarded with this in mind. Performance reviews are a waste of time as staff defend themselves rather than learn how to improve their performance.

A good manager is not necessarily someone with a high IQ who can argue his case very logically. The interpersonal skills are more important. A good manager is trusted by the staff because staff trust the motives of the manager. A good manager is accountable and sets a high standard. If you're interested in more, click here for David's website or click here to access the recorded web seminar from Changepoint.

Project Management is a critical success factor in the success of any project

Project Management is a critical success factor in the success of any project, but many organizations don’t use a project management methodology and don’t have tools to assist in the process. For a resource on project management methodology, consider joining the Project Management Institute (http://www.pmi.org), with more than 20 chapters in cities across Canada. You could also check out the Solutions Network (http://www.solutionsnetwork.com/) which issues a quarterly newsletter on project management at no charge and hosts the ProjectWorld Exposition and Conference held in a number of cities including Toronto and Ottawa.

CIO Insight suggests a number of other sites, Click here for their recommendations.

The most difficult part of being a project manager is saying “NO”

In our Case Study of the TECSYS implementation at Hubbell Canada Inc., we wrote that the most difficult part of being a project manager is saying “NO” to the many compelling demands to avoid scope creep (adding functionality to agreed-upon scope). Senior Management needed to provide full support in not allowing the scope of the project to broaden. The implementation project also required attention to details by the project manager in testing the system thoroughly and keeping the schedule up-to-date and accurate. It also took great communication skills to keep the team motivated, and the naysayers on-side. Project management was a critical success factor in the implementation of TECSYS at Hubbell Canada. Click here for the TECSYS case study.