Human Resources has successfully transitioned to PageUp, our new recruitment and onboarding system. PageUp is now live for applicants and the University community.
Happy New Year!
One of the biggest challenges facing technology projects is risk. Risk is an inherent and unavoidable part of taking on a project, but it can be managed. This post from the LiquidPlanner blog highlights 9 steps that can help manage risks (and uncover potential opportunities!) in your next project.
Every project encounters challenges. How the team handles them, and what they learn, can be a valuable tool for future projects if it is leveraged properly.
This months post comes to us from Kenneth Darter over at Project Smart. He discusses proper methods to document Lessons Learned in your project (both positive and negative), when to document, and how to bring that knowledge forward to run future projects more effectively in your organization.
Are you using Lessons Learned to their best effectiveness in your project?
It’s February, and the change of seasons is fast approaching, so now seemed like a great time to talk about Change Management. Change management is a complex, and often overlooked, component of projects. It’s critical, however, to understand that change must be managed since it is an inherent part of every project.
This piece from The Balance gives a nice in-depth overview with clear examples of how PM’s navigate and manage formal (and informal) changes on their projects.
See you in the Spring.
Happy New Year!
This month’s post is an “infographic” provided by Taskworld, and it gives explanations for thirteen common Project Management terms.
Many of these are common sense, and if you’ve worked on a project you’ve probably heard them (especially from your PM!) That said, you may not have, and it’s a handy primer that all project team members should be familiar with. Communication is a huge part of project management, and if your entire project team is “speaking the same language” and familiar with common expressions, it can increase their chances for success.
One of the first things to do when you start a new project is to work out what it actually involves. As well as all the workshops about requirements and the documentation that results, there are some other things to investigate as part of your project scope.
Sit down with your project sponsor or other key users on the project and go through this checklist of 7 questions you should be asking about your project scope. They’ll appreciate that you have taken the time to ask and you’ll get a much better understanding of what they are expecting the project to deliver on their behalf.
This month’s post comes by way of Duncan Haughey from ProjectSmart.
Duncan provides some important (and often overlooked) rules for requirements gathering, which is a key component of any project’s success.
Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. Requirements gathering sounds like common sense, but surprisingly, it’s an area that is given far too little attention.
Many projects start with the barest headline list of requirements, only to find later the customer’s needs have not been adequately understood.
One way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:
- A succinct requirement specification for management purposes.
- A statement of key objectives – a “cardinal points” specification.
- A description of the environment in which the system will work.
- Background information and references to other relevant material.
- Information on the primary design constraints.
This month’s post is courtesy of the Center for Testing Excellence.
Testing is a key part of nearly every successful project. But do you know the difference between a testing strategy and a test plan? This article provides some great detail in defining the roles of both.
A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.
The Test Strategy document is a static document meaning that it is not updated too often. It sets the standards for testing processes and activities and other documents such as the Test Plan draws its contents from those standards set in the Test Strategy Document.
Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is fine and it is usually the case for small projects. However, for larger projects, there is one Test Strategy document and different number of Test Plans for each phase or level of testing.
This month’s post comes from the folks over at MindTools, and discusses the use of “Phase Gates” as they relate to project management.
What Is A Phase Gate and How Do I Use One?
For all but the smallest projects, experienced project managers use well-established project management methodologies. These are often published systems – such as PMBOK (Project Management Body of Knowledge) or PRINCE2 – but they can also be in-house methodologies that are specific to the organization.
These approaches have some differences in emphasis, and they tend to use slightly different terminology, but they generally share two key features: projects are delivered in stages, and certain common project management processes run across these stages.