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.
Happy Spring!
This month’s post comes to us from the folks at Capterra, and discusses the five biggest trends that are shaping project management in 2018. Some are new, and some extend from processes and methodologies that gained some significant traction through 2016 and 2017.
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 Float 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 Visually, 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.
These terms are being thrown around a lot lately in the testing community, and they can cause some confusion the first time you hear them being used in this context. They definitely confused me the first time I heard them, so I will attempt to provide some clarification in this post.
I have found that heuristics and oracles provide a great starting point for testing, especially when little is known about the product, and they frequently result in more thorough tests. They also help to label methods and processes that would otherwise be difficult to explain. Labeling these processes makes it easier to improve them. But what are they…? Continue reading
Excerpt taken from the Software Testing Body of Knowledge for CSTE
The “basics” of software testing are represented by the vocabulary of testing, testing approaches, methods and techniques, as well as the materials used by testers in performing their test activities.
There is often confusion regarding the difference between quality control and quality assurance. Many “quality assurance” groups, in fact, practice quality control. Quality methods can be segmented into two categories: preventive methods and detective methods. This distinction serves as the mechanism to distinguish quality assurance activities from quality control activities. This discussion explains the critical difference between control and assurance, and how to recognize a Quality Control practice from a Quality Assurance practice.
Just as there are various models for the SDLC, there are different “schools of thought” within the testing community. A school of thought is simply defined as “a belief (or system of beliefs) shared by a group.” Dr. Cem Kaner, Bret Pettichord, and James Bach are most often cited in regard to the “software testing schools.” They are also responsible for creating the Context-Driven approach to testing. The first real discussion about these schools was by Bret Pettichord (2003) who described the following four schools. Since that time, Agile and the Test-Driven school were added to the list.
This month’s article comes from the PMTIPS blog, and focuses on some key questions your team should ask when defining the scope of your project.
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: