IN THIS ISSUE:
FUTURE TUG EVENTS:
- November 30 - MoM @ The Savoy
- May 2nd & 3rd - TEC 2017
All-day PHP Workshop with Mike Pavlak
Another special day for TUG members and other IBM i professionals
Tuesday November 8th, 2016
8:30am - 5:00pm
Full day session where students bring their own laptops and connect to an IBM i LPAR running PHP in the cloud. The workshop includes 4 presentations with 4 corresponding hands-on lab sessions covering all of the fundamentals of PHP .....read more.
Price: $249 for Members / $299 for Non-members
The Monte Carlo Inn, Markham 7255 Warden Ave (at Denison Street) Markham, Ontario L3R 1B4
Register at: www.tug.ca/PHP2016/REG
Back To Top
Article: Introduction to IT Project Risk
By Debbie Gallagher
While working on a variety of IT projects, I’ve seen several project charters and risk registers. Over time, I’ve noticed that not all project managers have a solid grasp of how to identify and mitigate project risk. So, here’s an introduction to the subject.
These aren’t project risks: Perhaps it seems an odd place to start, but the most common problem I see is that many risks identified aren’t really risks. So, what is not a project risk?
An issue is not a project risk. An issue is something that is already a problem for the project. E.g., a risk item that states: Vendor is late delivering components. Since the vendor is already late, or you already know the delivery is going to be late, this is an issue, not a risk. A risk is something that could happen, but hasn’t happened yet.
An outcome is not a project risk. E.g. a risk item that states: The project might not go live on time. This statement is an outcome of one or more events that could happen, for which the outcome is that there could be an impact on the project timeline. A risk is the thing that might cause the project to go late or cost more, etc.
Also, a vaguely-defined concern isn’t a risk. Risks aren’t really properly identified if they are not specific. E.g. a risk item that states: Testing is a risk. This statement is too vague, as it doesn’t say what specifically about testing is a risk and why it is being identified.
These aren’t mitigation plans: In addition to incorrectly identified risks, I often see vague mitigation plans. E.g., Manage dependencies and milestones. E.g., Leverage vendor’s experience. These mitigation plans are too vague to be actionable.
What are we worried about? What will we do about it?
Every book on project management has a risk definition along the lines of “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.” (PMBOK, Fifth Edition). Following that, there’s a definition of risk mitigation, such as: “Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk.” (PMBOK, Fifth Edition)
Although accurate, these definitions can be simplified to aid understanding. The easiest way to identify risks is to ask yourself and others: What exactly are we worried about and why are we worried about it?
Then, once the worry and rationale are very clearly defined, the mitigation plan is based on: What very specific actions are we going to take regarding that worry?
Do you have reason to believe the vendor might deliver late – before it happens? For example, maybe the vendor has recently made a lot more sales than usual and you’ve had late deliveries when you’ve bought from other fast-growing vendors. If so, you can record the risk very clearly: Vendor has gained significant market share in the last three months. Based on our experience with other vendors, this market gain can have an impact on manufacturing capacity, which may result in late delivery.
If you want to avoid this event, think about what options you have to avoid your project being derailed by late delivery. For example, if the contract isn’t signed yet, can you build in a penalty clause, or pay a premium for on-time? Can you spend extra effort on vetting your requirements to ensure your own project doesn’t cause any impact on the vendor? Do you have access to other equipment you could use temporarily if the delivery is late? Does that strategy lead you define an additional risk and mitigation plan? Ask others for ideas on how they’ve managed this kind of risk before and how successful the strategy was for them. Be specific in your mitigation plan: go beyond platitudes such as good project management.
Do you have other worries?
Anything that causes you a specific concern is a candidate to be included as a risk. Risks are as varied as the projects on which they arise. Here are a few examples I’ve seen: (1) Servers are being moved from a company-run to an external data centre during the same time period that our project needs to test connectivity for several interfaces. Testing connections to the old data centre will need to be repeated for the new data centre, with potential for delay to our project’s timeline. (2) Although the on-site project manager assigned by a major vendor has great leadership skills, he’s not particularly rigorous about scheduling and tracking against the schedule. Since he is managing a large team and a tight delivery timeline, we are concerned that we won’t have adequate visibility to progress or lack thereof. (3) Previous upgrades to this application have failed due to lack of understanding of the integration points.
Notice that all of these risks are very specific, and they provide a rationale for why the risk has been identified.
Schedule and follow up
Assign a responsible person and due date for every mitigation action item. If you aren’t able to assign a person and due date, the mitigation step probably isn’t defined clearly enough. Track these mitigation steps to make sure that they actually get accomplished.
Understanding of IT project risks and mitigation plans can be improved by simplifying the definitions to: (a) What you are worried about exactly and why; and (b) what you will do about it.
It is important to be very specific and provide the rationale for the risks. The mitigation plan needs to be detailed enough that each task in it can be assigned to a person and on a specific date.
Debbie Gallagher is a project manager and business analyst.
She can be reached by email at firstname.lastname@example.org. Previous articles are archived at debbiespmtales.blogspot.ca.
Back To Top
Thursday Oct. 27 & Friday Oct. 28 at Seneca @ York.
This event is hosted by Seneca College’s Centre for Development of Open Technology, the Free Software and Open Source Symposium which brings together users, makers, and creators of all things open source for two days of informative talks, workshops, and industry networking. This year’s event promises to be bigger and better than ever before.More info at: http://cdot.fsoss.ca/
Back To Top
Sign up now for iDevCloud! You will be able to:
- Share between multiple developers
- Get private library and storage
- Have access to most of the IBM i development tools
- Have all compilers for IBM i tools available
The Performance is monitored by system managers with adjustments as needed. The system is accessible at anytime from anywhere in the world. Just a computer and an internet connection are needed. Any work done on the system stays on the system until removed by its owner.
Contact Leo Lefebvre at email@example.com to get started.
(*Free startup for TUG members.)
Back To Top
November TUG MoM
Mark your calendar: Next Meeting of Members will be held on November 30th at the Monte Carlo Inn, Markham.
ADMISSION: Free to all TUG members
||Session 1: TBA
||Session 2: RDi, Release 9.5.1 with Mac support (Eric Simpson)
||Wrap Up and Door Prize draw
Stay tuned to the TUG website for more information ...
Register for the next TUG MoM at: http://www.tug.ca/reg_meet_form.php
Back To Top
Advance Info: TUG's TEC 2017 "TEC the i Train", will take place Tuesday and Wednesday, May 2 and 3, 2017 -- for the second time at the SAVOY Conference Centre (Monte Carlo Inn) 7255 Warden Avenue in Markham. We will feature the "cream of the crop" -- only the very best IBMi technical speakers. More details to follow.
Full Conference Rate:
• TUG Members $695 (plus HST)
• Non-members $795 (plus HST)
Early Bird Discounts:
TUG members save $150 on a full conference registration
until December 31, 2016 or $100 on a full conference registration
until March 31, 2017.
TEC is the Toronto Users Group’s annual Technical Education Conference. We have a very intense lineup of main themes including, but not limited to:
• IBM i & RPG Application Development
• Performance Management
• Web and Mobile Development on IBM i
• Modernizing your IBM i Applications
• Accessing and Optimizing IBM i data
• IBM i System Management
Back To Top
The Toronto Users Group for Power Systems (TUG) is a user group/forum for the exchange of ideas, and specializes in providing affordable education relating to the IBM iSeries, AS/400, System i, and Power Systems platforms. TUG is in its 32nd year of operation.
TUG is the proud recipient of a 2016/ 2017 Maxava iFoundation grant.