Rebecca Schmidt

Part A: Big Takeaways Related to Project Management

During the course of my professional career as an educator, I participated in the management of

Having recently transitioned into an instructional designer position, I have been tasked with
managing the design of around fifteen courses during a cycle. During my first cycle on the job, I
found that many issues popped up early on, resulting in timely revisions. One project even had a
change mid-cycle to the scope. Even more alarming is that several projects are still being
completed outside of the cycle dates due to unanticipated setbacks. As an instructional designer,
I have not been a part of the initial planning between the stakeholders (Associate Deans) and the
curriculum coordinator. However, based on what I have learned in this course, I have begun to
ask more about this process. I have also frequently vocalized the setbacks I have encountered to
provide more transparency about the risks that need to be planned for in the future. 

Even though I do not have a direct hand in all of the project management tasks during a design
cycle, I plan to incorporate many elements from this course into my current work and future
endeavors if I move into a curriculum coordinator position. Through this course, I have gained a
greater understanding of all the project management documents, the steps in the project
management cycle (Initiation, Planning, Execution, Monitor/Controlling, and Closeout), the tools
available, and the importance of communication among developers and stakeholders. The
content from each of the seven modules that helped make up the final project for this course has
helped create a clearer perception of the attributes of a successful project manager and the level
of work that should go into each project.

Although it was not part of the final project document, the work completed in the first module
related to developing a set of team expectations and values was beneficial. By developing a set
of expectations, we reduced the likelihood of misunderstandings in the future. We were also able
to keep our expectations for each other in check. We knew the best ways to communicate and
were able to keep each other accountable. It helped us all feel that we had a voice on the team. I
can be a perfectionist at times and am used to taking control of a project. By developing this
contract of team conduct expectations, I am better able to manage my expectations for my team,
which in turn can improve team morale. Hopefully, as my team at work is finalized, we will take
the time to conduct a similar exercise to develop a set of values and expectations to build a
cohesive working unit.

The gap/needs analysis was a familiar concept from previous courses, but the project reiterated
the value of the gap analysis. It allows you to get a clear vision of all of the needs an
organization may have, whether they relate to instruction or not. It also is useful to refer back to
when developing the scope (and not in scope) statements for a project. Additionally, it helps you
brainstorm possible solutions for a need. In my current position, it seems like we uncover a new
organizational need weekly. Whenever we bring it to light, it becomes an immediate initiative,
which can be overwhelming when you already have a full caseload. It would be beneficial for
our organization to conduct a gap analysis and use it to prioritize projects.

The charter development that was part of our final project was my first exposure to formal
initiation documents for a project. It caused me to consider all of the stakeholders and how it is
important to keep them involved in all stages of the process through open and continuous
communication. Because of this, I have begun to initiate more frequent communication with my
stakeholders, the associate deans. I hope that by being transparent throughout the process and
getting their input, there will be less need to rework elements of the project later on.
Additionally, the charter showed the importance of developing a business case and statement of
what is in and out of scope. By including these elements in the charter, we can ensure that
stakeholders have common expectations for the project. Identifying potential risks and any
assumptions was also a big takeaway for me. If you prepare yourself early for risks, you can
develop mitigation plans and even counteract those risks so they do not affect your project
timeline. Likewise, assumptions need to be investigated to ensure that there are no surprises later
in the process if they do not hold true. In my organization, I feel that more emphasis should be
placed on developing statements related to risks, assumptions, and the scope of a project to
ensure that stakeholder expectations remain in check. Even if it is not formally completed by my
supervisor, I will be keeping track of these items.

The scope management document built on the work inside the charter. It mapped out the
workload and the responsibilities of all parties that are involved in the project. It indicated the
communication methods used and ways to control change to the scope of a project. It also
included a schedule with all the deliverables and milestones for the project (based on the WBS).
I loved the formal process of initiating change to the scope of a project. Too often, a change gets
approved/made with little consideration for the impact it will have on the scope of the project.
By requiring a formal process to approve changes, it causes everyone to consider the
implications, which may reduce spur-of-the-moment project creep. Like the charter, the scope
management document gives a clear vision of the project and develops a common understanding
of the scope. However, it also digs deeper to show where responsibilities fall, the timeline for
each milestone/deliverable, and how the team will communicate successfully. Although it can be
time-consuming, the value comes from the details inside the document that help the project run
smoothly.

The design documents were probably the area that all of us felt the most comfortable. Acting as
an instructional designer, I have had many experiences working with terminal and enabling
objectives and determining activities and assessments that align with them. Interestingly, because
all of us have had experience developing objectives, it actually made it more difficult to finalize
things. We all had differing opinions for the best objectives to use, and all of the options seemed
reasonable. New to this course, we also developed an evaluation plan that consisted of formative,
summative, and confirmative evaluations in the design document. What helped us to successfully
develop this (and other documents) was that we would always come to our meeting with a set of
ideas bulleted on our templates. Then, we could discuss the content and narrow or add to the
sections as needed.
The facilitator guide was probably one of the most challenging aspects of the final project. Aside
from some technical issues (discussed in detail in Part B), it was challenging to determine the
level of detail to include in the instructional content section and to keep uniformity in that section
with three people constructing it. I tended to lean towards having more details in the guide than
my partners. However, after having some discussions, my team was open to adding “do” and
“say” prompts. The challenge was adding enough information to allow for consistency no matter
who the facilitator was. I leveraged some of my experiences of viewing lesson plans and
curriculum to determine an appropriate amount of detail to include in the facilitator guide.
Unlike a lesson plan, the guide included a set of facilitator expectations for before, during, and
after the training. This list of expectations served as a great checklist that a facilitator could use
to be prepared.

The execution documents that we developed were the last portion of our project and were
designed around a scenario where our vendor went out of business. It goes to show that one
change can impact many other aspects of the project. Often, the problems that surface in this
stage of the process are due to issues from poor planning in earlier stages. This makes it
important to document any changes and any learning experiences so that issues can be avoided in
future projects. I especially see the value of completing weekly progress reports to keep tabs on
the project and provide complete transparency to all parties involved (including stakeholders).
When I manage projects in the future, I will utilize documents such as progress reports and
meeting agendas/minutes to help document communication and plans for the project. I also will
attempt to organize a team and give them specialized responsibilities based on their strengths.

Overall, I have learned much about the project management process through the course of this
class. I feel much more comfortable taking a leadership role and handling the documentation to
help a project run smoothly.

Part B: Working as a Team 

Coming into this course, I was nervous about the team project. During my undergraduate
courses, I had some unfortunate experiences where individuals did not complete their share of
the work, leaving me to put in the extra effort to complete the project to the required parameters.
Thankfully, we were all motivated individuals in this course and were able to maintain constant
communication to resolve issues.

In the beginning, we took a week or two to really work as a cohesive group. We had to find a
communication method that worked well and problem-solve some of our technology issues.
Emails tended to be harder to juggle and could easily get missed in the shuffle, but texts seemed
too intrusive to start. We found that Google Chat/Hangout was the most efficient communication
method for us and regularly checked in with each other and gave progress updates. Weekends
were a busy time, and we sometimes found ourselves away from the computer for long periods
due to work or personal obligations. We would occasionally send texts to keep each other
informed of final changes or major issues that may have popped up in our weekly tasks.
As a group of three, there was plenty of work to spread among us. We tried to share the
responsibilities equally, and each would complete a portion of the weekly tasks. Each of us
would review the project management documents before our weekly meeting and jot down notes
to help us more efficiently use our time. One responsibility that I took was developing the
agenda for our meetings. As a team, we found that we worked best when we brainstormed ideas
on the project management document and had a starting point, so I tried to always have the
documents uploaded to SharePoint. The other members of the group took on the responsibility of
submitting our documents for feedback and grading purposes. Before each meeting, individuals
would research resources that could be used in that assignment. Everyone had the opportunity to
share their ideas during our meetings, with each person having a designated area to share their
ideas in the meeting agenda.  

Because we were transparent about our personal obligations, we were able to flexibly work
ahead and take on others’ responsibilities when we faced barriers. Rarely did we ever find that
we were without communication from each other for more than a day. We would set deadlines
for each portion of our assignments, which included having our tasks completed in time for
others to give us feedback.

At first, I am sure there was some anxiousness about giving and receiving feedback. I am
currently an instructional designer, so my teammates and I leveraged some of my experiences.
Over time, we all asked questions more comfortably and would share our thoughts on the best
approach to take.

This experience was able to stretch me. I am used to being a perfectionist and the source of most
ideas when working on projects. However, at times, such as when we were determining our
terminal objectives or the change request document, I found that our team had differing opinions
on the best approach to take. I wanted to push myself to follow the best practice as a project
manager to listen to your team and not interject your personal opinions until your team members
have had a chance to share their thoughts. I saw the “political” side of project management and
realized that by making concessions, the team as a whole would be more successful. As a team,
we were often able to discuss the pros and cons of each choice and come to an agreement. It was
powerful to hear everyone's voice in the process. In the team environment that we created,
everyone actively participated, listened to each other’s thoughts, and felt comfortable asking
questions and sharing ideas. Everyone was focused during our meetings, but we were
understanding of each other since we knew that we all had families that may require our
attention.

As a team, we had several technical setbacks that required us to stretch our problem-solving
skills. The first dealt with our virtual meeting tool. After our first few meetings, we were
beginning to be kicked out midway through the sessions. One team member, Kristina, took the
initiative to attempt to start virtual meetings with several other programs (Microsoft Teams and
Google Meet). As a team, we agreed that Google Meet worked best and moved all meetings to
that platform. Unfortunately, I was not able to share my screen with this platform due to the
privacy settings on my computer. As a team, we decided that Kristina could be our navigator
who always shared her screen.
One of our biggest problems that we had to overcome came when we were developing our
facilitator guide. Our goal was to complete this document a week early so we could complete the
rest of the modules a week early. We had had a few issues with SharePoint not syncing up and
losing a paragraph or two a week earlier. Knowing this, we made sure we refreshed often and
looked over each other’s sections to catch any syncing issues. Even with our safeguards, we
found that SharePoint backfired on us. On the Saturday night that we intended to submit the
facilitator guide for feedback, I looked it over, and everything was completed and formatted
correctly. I closed my computer around 10 pm and went to sleep.

A few hours after I woke in the morning, I decided to look over the document to view any
feedback we may have received. To my dismay, two enabling objectives worth of content were
lost. Additionally, another couple of sections of the instructional content were no longer
formatted correctly. My quick solution was to go into the history of the document to Saturday’s
versions and restore that version. When I looked back, I was shocked to find that all of
Saturday's versions were experiencing the same glitch. I ended up having to restore a version
from Friday, which meant that all of the revisions and reworks that another member of the group,
Orsolya, was lost.  

We were grateful to have had an older version to restore and work from. We were even happier
that we had decided to work ahead and had time to make the fix-ups rather than rushing on the
actual due date. In the end, I spent a good chunk of the morning reformatting since my partners
had other personal responsibilities to attend to. This helped Orsolya to be able to reconstruct the
remaining portions of her work and fill in any gaps that I may have missed. In the end, this
served as a reminder of the importance of building in buffer time and remaining in constant
communication throughout a project.

I grew as a teammate and leader through this process. I worked to try to include everyone in the
process and actively seek my teammates’ opinions. I developed our team agendas and preloaded
our templates with possible starting points to build off of. I would give feedback regularly and
worked to address any questions from my partners. I spent extra time reviewing our documents
for quality and problem-solve when needed. 

Although working in a group can be difficult, many benefits came from this experience. I valued
the strengths and ideas of my teammates. Orsolya often brought a different perspective to the
conversation, having come from a profession outside of the teaching field. Her opinions on the
strategies and resources to use often differed from my own, which resulted in deep and
meaningful conversations. She always was open to listening to feedback and maintained a
positive perspective in the face of challenging situations. Kristina brought a high level of
organization and facilitated many conversations inside and outside of group meetings. She took a
personal interest in everyone’s lives and helped create a work environment where we made
deeper connections, which resulted in us building a team based on trust and understanding. She
was always willing to ask questions, give feedback, and find answers through additional
research. When participating in future projects, I will try to bring these same characteristics to
my teams.