2 Structural Frame Worksheet

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 4

OGL 481 Pro-Seminar I:

PCA-Structural Frame Worksheet


Worksheet Objectives:
1. Describe the structural frame
2. Apply the structural frame to your personal case situation

Complete the following making sure to support your ideas and cite from the textbook and other
course materials per APA guidelines. After the peer review, you have a chance to update this and
format for your Electronic Portfolio due in Module 6.

1) Briefly restate your situation from Module 1 and your role.

I am an associate project manager for the billing team at Zelle. My team makes
maintenance and enhancement software upgrades to the organizations billing interface.
Along with managing and uploading the millions of product files to the billing system,
which cranks out the back-end invoices. My main stakeholder and customer are the same
person. My job as a Project Manager is to implement and facilitate SCRUM
methodologies and practices to improve workflow, reduce risk and mitigate problems
related to the scope schedule and budget of our initiatives. My analysis of the current
environment showed me that the lack of clear, and mutual understanding of the
requirements being handed sown from the stakeholder to the development team was the
root cause of the teams largest issues – and from it stemmed a myriad of symptom issues.
Inaccurate work estimates lead to innacurate timelines and decreased work-life balance
(working out of schedule). Improper execution of SDLC phases due to re-work, after-
the-fact-changes in production and testing in production. Further analysis showed that a
key responsibility was not being fulfilled by the stakeholder (and product owner). They
were not formally submitting user stories (formal description of the feature they would
like the development to build from the perspective of the end user). I held multiple
meetings to walk them down my roadmap. From user story training, implementation,
support, reporting metrics to key performance indicators. My stakeholder was in
agreeance, attended the training session and agreed to implementation standards and
schedules. The due date passed and we entered into a state on non-compliance. Multiple
attempts were made formally and verbally to garner compliance. Action was still not
taken. A delicate situation that left me negotiating upwards. For reference, I am an
Associate. The stakeholder is a Sr. Director. I could have escalated the situation to my
resource manager. The biggest question here is why I wasn’t receiving compliance and
what my possible avenues were? I chose to wait until our on-site, and strategically started
a workshop session where the team and I walked the business through submitting our

1
next set of user stories. Ultimately we garnered compliance but it remains to be seen
whether they will comply on their own in the future.

2) Describe how the structure of the organization influenced the situation.

One lens to describe why the product owner was not submitting user stories is through
identifying contextual variables (Bolman, Pg. 100) related to role flexibility. The
organization went through two restructures that decentralized the project management
organization and left teams to self manage. Looking at the situation through this lens
could mean that someone else took over the submission of user stories – and that the
stakeholders required far more training than I had initially thought. The non-compliance
in my opinion is not considered a blatent disregard of role responsibility if the previous
environment did not follow that procedure. Another way to analyze this structure is to ask
whether it is too loose or too tight (Bolman, Pg. 78). The role responsibility environment
is equateable to the wild wild west. There is no documentation of process mapping, no
clear understanding of role responsibility and little visibility into individual contributions
of work, problems and oprrotunitites. Prsonally I think the fast and lose role
responsibilities may have led the stakeholder to believe he did not need to adhere to rigid
rules as hard deadlines. Finally you could also analyze the upwards power struggle
stemming from the Product Owner, Main Stakeholder and Customer being the same
person. I have no outright authority over this Sr. Director so I had to be very careful when
navigating the situation. I not only want but need to have a solid relationship with him.
He has ultimate say. Because of that I may have tread to lightly. Perhaps I did not stress
the importance of the task or deliver the expectations in a matter-of-fact way.

3) Recommend how you would use structure for an alternative course of action
regarding your case.

If I were to be at the forefront of this situation for the first time again I would first tackle
it by implementing structure around rules an policies. The trivial pursuits we lacked; Role
assignments, communication standards, who should do what, how we make decisions and
how to handle situations (like non-compliance). Implementing structure around these
types of rules would have all but eliminated the potential option to escalate the situation
to my resource manager as we would already have a roadmap for how to handle such an
issue.

Structurally it does make sense to me that we operate in a more vertical way however I
do think it could be impeding us from acting as true collaborators. In this situation I felt
like my initiative was being stifled because I had to work upwards through one overruling
force that acts as 3 constituents rolled up into a single person. If we decentralized the

2
authority (at least in some respects or some elements of the project) I do think we would
see more creativity and intiative, along with less fear (Bolman, Pg. 64).

4) Reflect on what you would do or not do differently given what you have learned
about this frame.

For starters I would have approached my roadmap to our opprotunites from a place of
strategic structure starting with rules and procedure mapping. My team did not have clear
indication of roles or responsibilities. They are very autonomous and self regulate, but in
ever-shifting and changing boundaries. I believe in agile mindsets stemming outside of
the SDLC lifecycle. Meaning that so long as we are complying with SDLC and audit I
am open to defining our roles, our jobs, and our responsibilities in a way that makes sense
to everyone. One that fits to our teams individual working styles and needs. I think
implementing in this way, especially in true collaboration with the team would foster a
bit of a switch (at least in mind-set and collaboration dynamic) towards having more of a
lateral structure. After all, our main stakeholder additionally owns the functionality of the
billing portal we use so he is very involved collaboration efforts from an architecture
position.

Additionally, I would also make it a point to develop my strategy more and provide more
visibility to it from the teams perspective. My training and implementation plans were
good however my perspective on how we should account for work was not weaved into
my plans in a way that made sense to my team. I also did not speak of my analysis finds
when talking about my plan or my roadmap. Perhaps if the team was able tl see the
working patterns that I did they would be able to make the same conclusions I have
which would inspire them to find solutions. Hopefully in the form of my trainings.
Overall I am proud of the way I handed the situation as it was my first conflict, however
there is always opprotunities for growth.

3
Reference or References
Bolman, L. G., & Deal, T. E. (2021). Reframing organizations: Artistry, choice, and

leadership (7th ed.). San

Francisco, CA: Jossey-Bass (ASU Bookstore Automatic Purchase-Perusall Version

Only)

You might also like