TUG Meeting of Members
Wednesday, October 26, 2011

Living Arts Centre, 4141 Living Arts Drive, Mississauga
ADMISSION: Free to all TUG members
Keynote: Power Systems™ October 2011 Announcements: What do they mean to you!

With a new season ahead, the month of October 2011 is extremely busy at IBM with regards to products announcements at all levels — including Power Systems hardware and software.

TUG's October 2011 Meeting of Members will help you understand why you should pay attention to the recent IBM announcements.

AGENDA:

4:30 Sign up & Greeting

5:00 Session 1: October 2011 Power Systems Announcements.

• Speaker: Dale Perkins
• Dale will provide detailed information on all main announcements made by IBM since October 3, 2011. Hardware and Software.

6:00 Intermission (Buffet Dinner & Networking)

7:00 Session 2: - Deep-Dive into the announcements

• Speaker: Dale Perkins

8:45 Wrap Up and Door Prize draw

BIO:
Dale Perkins is a Consulting IT Specialist with IBM providing Technical Support for Power Systems. He works directly with IBM customers primarily in the Finance and Retail industries to assist them in building robust and flexible infrastructures. Dale has been with IBM for 30 years starting focusing on the mid range product line starting with the System/34 and the System/38. During his time at IBM he has spent most of his time working directly with accounts. His roles have included, Systems Architect and national responsibility for Server Consolidation on System i, and new workloads like windows integration and telephony. He has a Masters Degree in Computer Science from the University of Saskatchewan and is an IBM Certified IT Specialist.

Back To Top

TUG Meeting of Members
Wednesday, November 23, 2011

LOCATION: IBM Toronto Lab. 8200 Warden Ave, Markham
ADMISSION: Free to all TUG members ($40 non-members)
Keynote: Rational Developer for Power (RDP): What's New & Exciting?

AGENDA:

4:30 Sign up & Greeting
5:00 Session 1: RDP

• Speaker: Kushal Munir
• Kushal will review all the new features and enhencements recently made available to Rational Developer for Power Systems

6:00 Intermission (Buffet Dinner & Networking)

7:00 Session 2: - Open Access: RPG Edition:
The 'What', the 'How', the 'Where' of the Handlers

• Speaker: Barbara Morris

8:45 Wrap Up and Door Prize draw

Back To Top

Member Article:

By Debbie Gallagher

In job ads for IT project managers, there is a heavy focus on being able to deliver on schedule and on budget.

In addition, at a course I attended this summer, there was quite a lively discussion of the role of the project manager: should they be accountable for anything at all beyond schedule and budget?

I’ve also observed that the first questions from the sponsor and from the steering committee are invariably “how much will it cost” and “when will it be done”. Again, the focus is on schedule and budget.

Why are schedule and budget the big focus of project managers and the executives for whom they deliver projects? Is that where all the big risks are?

The big risks
In my opinion, schedule and budget overruns are not the big risks themselves. They are the outcome of other risks that have occurred. So, what are the biggest project risks that drive schedule and budget problems?

In my last article in TUG Buzz (December 13, 2010), I reviewed Tom Kendrick’s book “Identifying and Managing Project Risk”, in which he outlines his findings from examining hundreds of technical projects. In the book, all the risks that occurred were translated to a timeline impact so they could be compared. I think it’s a fair assumption that when the timeline is extended, the cost also grows.

So, what are those risks that have the greatest impact? From Kendrick’s book, two risk areas with the greatest impact are: (a) non-mandatory scope changes; and (b) legitimate, but not anticipated, requirements gaps.

In other words, the big risks are related to scope and requirements. There are plenty more risks, but let’s start with these two. When these risk events occur, there is an impact on the schedule and budget.

Managing scope and requirements
There are several ways to focus on scope and requirements. Let’s go over some.

First, these need to be defined as clearly as possible at the outset.  Too often, there is a rush to get the project started, and it begins with inadequate descriptions of scope and requirements. This rush to delivery can lead to disastrously large impacts on schedule and budget.

Sometimes, there is a good reason to have uncertainty at the start of the project.  In that case, identify the lack of clarity as a project risk. Then, make sure that everyone on the project and on the steering committee knows about that risk. Also, include a re-assessment point in the schedule and funds in the budget to address the cost of potential changes.

Next, focus on requirements and scope during the project.  At the outset, meet with the project team(s) to review these in detail and address any questions. It is crucial that the team knows what is to be delivered.

Make sure there is a change control process and that it is followed.

Review and follow up on the project issues frequently. Issues are often the result of disagreement regarding what is in scope or what is needed. Too often, issues are logged in a database and neglected.

During the project there should be checkpoints to verify that the project team is on track. Hold walkthrough meetings with team members, and also with stakeholders outside the team. While often seen as time consuming, these walkthroughs are critical tools to ensuring the delivered product supports the requirements and scope of work.

An effective way to determine during the project if there are issues with scope and requirements is to ask team members informal questions about what they are working on, whether they are clear enough on what they need to do, and what problems they are having.  The project manager needs to make herself available when there are questions from the team regarding scope and requirements, and not put them off while heads-down adding up budget hours or updating Gantt charts.

Testing is another method of ensuring that the delivered product meets requirements and scope. Evaluate test plans to determine if they engage the right people and cover the right tests to identify gaps in scope and requirements. Ideally, gaps should be identified before testing, but even if found during testing, at least they are dealt with before go-live.

Conclusion
When hiring and evaluating project managers, the heavy focus on schedule and budget overlooks the relationship between schedule and budget, and project risks.  It’s usually the project risk events occurring that cause the budget and schedule problems.  Managing the schedule and budget is really about managing the project risks. In this article, I picked two top risks and discussed common techniques to manage them.

I’ll leave you with a couple of thoughts. First, I think the question from my course about whether the project manager is responsible for anything besides schedule and budget has a definitive answer. Project Management Institute says yes, as the knowledge areas cover a lot more than schedule and budget.  Quite apart from PMI’s body of knowledge, the answer has to be yes, because if you aren’t managing the project risks, it isn’t possible to manage the schedule and budget.

My second parting thought: If the project comes in on time and on budget, but does not deliver the expected scope or meet requirements, what was really achieved?

Copyright 2011 – Debbie Gallagher

Debbie Gallagher specializes in project management and business analysis. Debbie previously worked as a systems implementation consultant, and as an IT project auditor. She can be reached by email at debbie@gallaghers.ca

Back To Top