Employees get 50-75% of their relevant information directly from other people. All project management begins with knowledge; one of the most critical organizational assets—intellectual capital—is held captive in the minds of individuals. How to capture, share, retain and reuse this knowledge is the greatest challenge facing organizations today.
This interview with Benjamin Anyacho (LinkedIn Profile) and Bruce Moore (LinkedIn Profile) was recorded at the PMI® Global Conference 2019 in Philadelphia, Pennsylvania, USA. We discuss how to create/establish a robust knowledge-sharing environment intelligently, leveraging it for exponential growth, competitive advantage, and innovation.
Our discussion also looks at intelligent approaches to managing competencies, capabilities, and critical knowledge assets of the organization strategies for converting, capturing, sharing, as well as ways to retaining/reusing project knowledge to achieve innovative solutions, and value
What if you had to do your project in (near) half the time as previous projects, or be fired? What if your customer required you to do their project in (near) half the time to which you are accustomed or lose the business?
Hear about the techniques (that can be applied to almost any type of project) that helped to meet these challenges and got the products successfully to market in record time.
This interview with Douglas Knutzen was recorded at the inspirational Project Management Institute (PMI)® Global Conference 2018 in Los Angeles, California.
You'll hear about how to leverage scheduling, execution and team techniques to significantly increase speed on your projects, and (almost more importantly) how to lead project teams in high-pressure situations.
Successful projects result in change. However, this transformation usually happens when the original project team is already disbanding, leaving the process largely unmanaged and stakeholders ill-equipped to use the deliverables as they were intended, diminishing the expected project impact and benefits.
In this interview, we explore five strategies that project managers can easily incorporate into their project plans to put in place preventative and mitigation strategies that will lead to improved adoption of project results.
This interview with Eleonore Pieper (LinkedIn Profile) was recorded at the diverse Project Management Institute (PMI)® Global Conference 2018 in Los Angeles, California.
We look at a scalable model of five strategies for change and discuss how to modify plans with specific tasks in the areas of communication, training, organizational design, sponsorship and HR management to ensure successful post-project transformation.
As you study for the Project Management Professional (PMP)® exam or even during your practice as a PMP® credentials holder, you may end up questioning if a change request is required when a defect is found in a project. That seems like a complex question but has a very simple answer – Yes. You may be wondering if that still holds true if it is a minor fix? For something that would be a small quick repair? Something you are not even sure needs to be fixed or even impacts the project? How about if the defect repair would take less time than filling out the change request form? The answer is still…Yes.
How do we get to a yes, each time? Let’s take a look at a few definitions within A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Sixth Edition. First, as you probably know, it is the Perform Integrated Change Control process that governs everything concerning changes on a project. Per the PMBOK® Guide, “Perform Integrated Change Control is the process of reviewing all change requests; approving changes to deliverables, project documents, and the project management plan; and communicating the decisions.” (pg. 113).
What is a change request?
A change request is a formal proposal to make a change on the project, and per the PMBOK® Guide “may be a corrective action, a preventive action, or a defect repair” (pg. 93). Defect repair, in turn, is “an intentional activity to modify a nonconforming product or product component” (pg. 96). Lastly, depending on the policies and procedures of your organization, you may need to gain approval for change requests from a change control board (CCB) which is defined by the PMBOK® Guide “as a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project and recording and communicating such decisions” (pg. 115).
Ideally, projects would be completed without any defect repairs being needed, but since that is fairly unrealistic, projects typically build in some time, funding, and resources to deal with repairs that are needed as the project progresses and at the end once final testing has been completed.
Let’s take a look at a practical example. You are leading a software development project. One of its deliverables is a web interface where users can fill out a form and submit it using the “Submit” button. According to the specifications, the "Submit" button should be green. A tester finds the button is red. Is this a bug, or using formal language, a defect? Yes. Should it be repaired? Likely yes. One may argue it depends. But for the sake of simplicity, let’s assume the color of the button is one of the acceptance criteria. If the deliverable is not accepted, the defect should be repaired.
First things first - how should the tester notify the developer there is a defect? It depends on the organization’s policies and culture. The tester could send an email, make a phone call, or even visit the developer to discuss what they have found. How are defects typically reported and tracked? Through the use of defect tracking tools such as Bugzilla, JIRA, Plutora, etc.
Once the developer is made aware of the bug (aka defect) they then can analyze it. Hopefully, they are able to identify the root cause, can provide options to fix it (such as using configuration or hard coding) to make the button green, and are also able to provide an estimate on how long it will take to correct the defect.
When the developer has completed their analysis, what happens next? The basic process calls for a bug (defect) review meeting to be held where each bug is discussed along with their suggested repairs, impact on the deliverable and other factors, and a decision is made to approve, reject or defer the suggested repairs. Assuming the repair is approved, the developer will implement the fix, and the deliverable of a green “Submit” button will be accepted. Everyone is happy with the end result.
Does every defect repair require a change request?
Let’s take a look again at what has just happened here in the context of the primary question: Does every defect repair require a change request?
The tester has filled out the defect report in the bug tracking tool. That report was a formal proposal to modify the deliverable (the web interface). A formal proposal to modify a deliverable is the definition of a change request. A change request does not have to be a fancy 10-page document, it can be a napkin if that is what your organization accepts. A bug tracking tool described in the scenario was just an example of what could be utilized to submit a change request in instances when a defect is found. The change request in our example documented the expected result (green button), the actual result (red button), provided a unique ID number for the defect, and any other details an organization wishes to track. Whatever tool is used, we hope it is clear now that a change request should be submitted each time a defect repair is required on a project.
Does every change request require approval of the change control board (CCB)?
Another related question is: Does every change request require approval of the change control board (CCB)? This answer is not so simple, as it depends. A defect repair requires resources and often impacts a project schedule, each of which can add costs to the project. When those costs require funds beyond what was established for the project, or if allotted funds for defect repairs have been exhausted, then a CCB is often consulted for approval. Some organizations require the involvement of the CCB for all change requests. Others do not have CCB at all, and in that case, often additional approval beyond the project manager’s one will likely be needed if the change request to repair a defect will require additional funding. In some cases, the change management plan may specify that changes of up to a specific amount of money (for example, $10,000) can be approved by the project manager alone, otherwise, the change request would need to be submitted to the CCB for approval.
Does every change request trigger the Perform Integrated Change Control (PICC) process?
Finally, does every change request trigger the Perform Integrated Change Control (PICC) process? Yes, it does. In the example above, the tester reported the defect, the developer analyzed the defect and provided a suggested correction with estimated time to repair. A defect review meeting then took place to decide if the suggestion would be accepted. What has just been described matches the definition of the PICC process where changes are submitted, reviewed, and decisions made. Like with the change request that can be submitted using a fancy tool or just a simple napkin, the PICC process does not have to be extremely formal and involve the CEO and all project stakeholders. The way the process is implemented depends on a variety of factors such as the organization itself, the change management plan, and even the specific project.
The thing to remember is every defect repair, no matter how small or inconsequential it may seem, requires a change request. Completing a change request triggers the Perform Integrated Change Control process, and depending on the organization, the change request may or may not require to be submitted to a change control board for approval.
Becoming better at project management and by extension also becoming a better project manager does not necessarily mean learning about and then also implementing the latest tools, techniques or methodologies. Instead, it can simply mean that you start paying attention in a particular way; on purpose, in the present moment and nonjudgmentally. That’s mindfulness.
Mindfulness as a business practice and leadership tool has seen a significant increase in press coverage lately. It originally started out as a means for improving yourself and your interactions with others but you will find that many leadership articles in the large business journals will make reference to it.
And so we are very glad to welcome Margaret Meloni (www.margaretmeloni.com) to look at Mindfulness for Project Managers with us today. We will give you a definition, discuss the benefits, but most importantly we go through a number of familiar project management situations to see how mindfulness will help us improve and become better leaders.