Prompt: As part of your discussion board, choose one example of a “best practice” in

projects to either introduce to your classmates or to comment on (if your chosen

example was already chosen). You can also share a PM "best practice" that you have
observed or experienced yourself, please just be as specific as possible in discussing it.

I admire the practice of establishing a “Scope Creep Parking Lot” as introduced in chapter 20 of
the HBR Guide to Project Management in the article Handing off Authority and Control by Ray
Sheen. It was a potentially easily implemented and useful tool. Too often, as managers, we are
brought great ideas that, while valuable, could derail the already established scope and
sequence of a project. I like this practice because it allows you to propose additional follow-up
projects that ultimately enhance or improve the work you are protecting initially from scope
and sequence disruption. It puts value on both the work at hand and the good ideas generated
around it. Not only does it give a place for proposals to live, it tells the people who bring them
that their idea is not being dismissed. Although there is not an associated case study for this
provided by the text, one can imagine a scenario when someone has an idea that would
enhance a project they are working on. The idea is a good one and team members wish to
pursue it as an option. However as the project manager, you are responsible for the
deliverables as well as adhering to the scope and you know that incorporating this new idea
into your current project will severely disrupt your scope. What do you do? If it is your
standard and consistently employed practice, team members will respect you for being able to
manage two sets of variables without having them negatively impact either. It is good for
morale? Can it give both projects their own due and respect the work that was done to
establish the original scope? This is a practice that I wouldn’t have thought of employing but
when deconstructed, makes quite a bit of rational sense.

I also greatly appreciated the last chapters that dealt with closing out a project. I have
personally been on projects where, at the end, people feel too tired to review their processes
and truly analyze their experience. In my experience, this is a fairly common mistake by teams
that don’t have formalized processes or competent project managers to demand a formalized
close-out process.

I work at an organization that is nine years old and have been there from its beginning. After
identifying the need to develop policy and procedure throughout our organization, I have
written several documents that establish the procedures to promote consistency, mitigate
potential risk and provide data for us to improve. The best part of my job was seeing the
response of the employees who had a lot of feedback to provide but, without a formalized
process, they didn’t know where to deliver it. I believe these employees now feel a greater
sense of agency to not only their projects but to the institution because the process gives them
a sense that their voices matter.

Reference:
HBR Guide to Project Management. (2012). Boston, MA: Harvard Business Review Press.