Pathfinder

Project Exodus

Project description

Pathfinder is a Power Apps Platform based application designed to enable a single source of truth for Portfolios, Programs, Projects, and Change Management. Certain benefits include:

• Rapid prototyping and development
• Personalization capabilities
• One intake point for multiple types of work
• Portfolio view of top-level initiatives
• Allows teams to manage their work in their tools (like Azure Dev Ops or ADO)

The goal of the project was to take all project data from multiple sources and migrate them into Pathfinder.

Problem being solved

Organization had projects and work being tracked and ran from various sources. There were significant silo's which made visibility into projects a concern for leadership. There wasn't a, "single source of truth", where they could go to get an overview of what the status was of any given project. Some teams were using ADO, or Microsoft Project, or Microsoft Power Point and Excel.

These projects are tracked and statuses gathered for use during an Monthly Business Review (MBR). Without a single source, Business Managers were forced to spend significant amounts of time tracking the statuses manually in whatever platform/tool they wanted.

My Role in the Project

I was the primary project manager. I created the project plan and tracked all the requirements throughout the project.

Steps to success

Project Exodus would solve this problem by migrating all of the data for all the work the organization does to a single source: Pathfinder. To be successful, I would need to perform the following:

1. Identify project data being migrated.
2. Track list of projects and update as needed.
3. Gather org requirements and manage their implementation.
4. Coordinate testing and validation of implemented requirements.
5. Communicate and train stakeholders.
6. Control and monitor data migration.
7. Verify and test to ensure all of the data was uploaded successfuly.
8. Streamline the portfolio and collect feedback.

Lessons Learned

What went well?

1. Learning Power Apps allowed for better bug reporting and tracking. Being able to relay accurate information to developers made resolving bugs more efficient.
2. Generating an accurate and predictable timeline was made easier by taking extra time meeting with stakeholders to more deeply understand the requirements.
3. Creation of a Standard Operating Procedure immensely cut down on basic how-to questions and allowed for self-service.
4. Implementation of Pathfinder Office Hours

What could have gone better?

1. Stakeholder engagement was low due to the lack of a more active project sponsor.
2. One person from the org attended the Pathfinder Training session pre-go live.
3. Despite open and frequent communications, some members of the leadership team were unaware of the Go Live date.

Conclusion

Despite the lag at the end, implementation of Pathfinder was successful and was fully integrated into the Rhythm of Business (ROB). Identification of useful features continues to be implemented and I manage those integrations as well as the project data. I assign/revoke permissions to users and track bugs.

NHO Playbook

The one-stop-shop for all things NHO!

Project description

The Global Learning and Development (GLD) New Hire Orientation (NHO) team needed a central repository for their entire NHO process. From the moment someone accepts an offer all the way to the three month mark, they required a platform that could both house and share that information. The Seattle Amazon office is the defacto flagship of the company's new hire orientation process and it was The GLD NHO teams goal to expand and share and combine knowledge.

Problem being solved

This project had several problems that would be solved by creating a central repository:

• GLD NHO team does not have a central location of information for all of their processes and tools. Many processes are housed by specific members of the team in silo's with very little, if any, visibility into it from others. If one member should move within the company, it would create
• Outdated information is rarely updated and is usually not updated in the right place. This creates more than a few documents that need to be verified as current with the process owner.
• These tools and processes are wholly unique to NHO in Seattle. The NHO experience is different depending on which location you onboard at. Sharing processes and tools among NHO sites would ensure a universal experience that Amazon consistentaly aims to improve.

My Role in the Project

I was the sole project manager for this project. My role was to interact with stakeholders, gather the required information, as well as research and implement the repository.

Steps to success

This project required two things: a suitable and scalable platform as well as fully up-to-date information on all processes and tools.

• Gather and validate all information related to NHO and its processes and tools.
• Create and implement standards for documentation.
• Research and select the best platform to utulize.

Lessons Learned

What went well?

1. Team engagement
2. Support

What could have gone better?

1. More time would have allowed for more "nice to haves"

Conclusion

Overall, myself and the team was very pleased and happy with the results of the project. Many teams reached out to be included into the platform so as to continue to share the NHO experience with each other. Here are a few screenshots of the project:

Delridge Community Center

Teaching our youth to code and lead!

This training program was for refugee children that was running alongside other programs at the Delridge Community Center. I built this program and designed it to teach students from ages 10 to 19 how to code, design, and lead teams of other students in building a web application. The program would last for 8 weeks and follow this weekly schedule:

• Week 1: Introduction to HTML and CSS
• Week 2: Continue learning HTML and CSS
• Week 3: Introduction to an Agile Environment
• Week 4: Form teams and begin projects
• Week 5 - 7: Continue projects
• Week 8: Present projects

During week 3, the students of the class were treated with a trip to the Big Fish Games studio. They were able to tour the building and meet the VP of Human Resources, Jonathan Maltos. Jonathan talked about how they believed in having fun while coming together to make great games.
Next, they were met by the Game Design Manager Brannon Boren to discuss what it takes to be a game designer as well as some introspection into what to expect in school.

As the program manager for the project, it was my job to create the curriculum and get feedback to better align it with the objectives for the program. I was also present to play the role as the Product Owner so that I could communicate to the teams what my requirements were for their projects. At he end of the program, I interviewed each student to acquire data about the project with the goal of improving the program for future cohorts.

2019 Computer Science Internship

In partnership with University of Washington - Bothell

The 2019 Computer Science Internship was working with the University of Washington - Bothell's Masters of Computer Science program. Students participating in our internship would be able to earn colleg credits through the summer. The internship was unpaid.

My role within the internship was the marketing for, as well as interview, candidates for the summer program. I also helped drive and create the objectives and tasks the candidates would be working on. It was critical that I find the right candidates as the positions we had to fill were entirely dependent on the types of tasks and work to be performed.

I was also put in charge of the research and acquisition of a suitable workspace that fit both the company budget as well as the needs of the team.

CK Employee Website

A more efficient and simple solution.

My role when first hired by this company was to be the Teacher Supervisor. I was to interview, manage, mentor, and train teachers who go to schools in the Greater Seattle area to teach kids how to code.

I immediately noticed that the employee website that teachers used to log hours and get information about the school they were teaching at as well as the curriculum they were teaching, was big and bulky. After interviewing many of my teachers, I came to discover that many teachers didn't even use the website for anything other than the time sheets. I was also privy to many conversations with administrators about how frustrated they were about the site.

After conducting many interviews with users and other stakeholders, I crafted an organized and well thought out plan complete with a design (above) to pitch to the owner of the company. My project was authorized soon after.

From my research, ease of access was the most sought after feature for the site. Both administrators and general users wanted to get to where they needed to go in as few clicks as possible while also being able to get more information within those clicks. First thing that I did was I created a UX test that had three tasks. A user would take this test to complete the three tasks as I timed it. This would provide me a starting metric to test to verify project success.

I created all of the Epics, User Stories, and tasks using Azure DevOps (ADO). For teachers, I changed their landing page to be a calendar. The calendar would then populate with that specific teachers classes for the month. Teachers could click onto that specific class to get more information. Whichever class they clicked into would present a new page that has the schools contact information, address, Point of Contact, as well as a space for teachers to be able to add new information such as, "Don't park in this parking lot after 5" or "New construction on Main street, take 2nd street to get inside.".

For administrators, they were to use the same landing page they had been using before, but with a rearranging of informatin. All links that had nothing to do with that specific administartors rights would not be visible and all unnecessary files were archived. The time sheet page also added more functionality to users by giving them the ability to edit past entires (up to a week) and to be able to add in miles driven.

During the project, I communicated heavily with users and stakeholders to keep them up-to-date on the progress as well as to attain feedback. After the project, the same UX test from before was conducted and each user that took the test showed an huge decrease in time required to complete tasks.

Onsite Calibration Technican Training Program

A "how-to" BC guide for new hires!

Due to a signed agreement, I am unable to provide any pictures or screenshots of this proejct.

When I was first hired on by BC Group International, I was taken into the Calibration Lab where I met all of the calibration technicians by the Service Manager. After the pleasantries, the Service Manager left and that was it. That was when I discovered that BC Group didn't have a formal training program for incomming new hires nor was there any sort of process in play that would dictate what happens when new hires arrive. Without any direction, I began working on a project to remedy this.

I took it upon myself to begin grabbing equipment and asking the Calibartion Technicians how to work on them. This was the beginning of my training and I took comprehensive notes. I focused on the two main aspects of the training program that a new hire would need before traveling to hospital sites: the tech side and the admin side.

The tech side had to do with all of the biomedical equipment a new hire might encounter while working. Anything from multimeters and safety analyers to defibrillator's and ESU analyers, I began to compile technical documentation to create standardized SOP's for new hires to use when they encounter the equipment. The SOP's also came with tech notes that dove into the specifications of the equipment, which resistors to turn, and when a piece of equipment was no longer qualified to be calibrated and needed repairs or replacement.

The admin side had to do with a program called, "Alpha". This program was used by the technician to log information, create calibartion certificates, as well as keep an up-to-date list on the equipment a site had. Alpha was a DOS program and required training in order to use.

I combined all of this into a training book complete with screenshotes of Alpha, SOP's, as well as a recommended training timeline for new hires to use. The goal of the project was to make it so that all the Service Manger had to do was hand them the training book and the New Hire could begin their training immediately.

As a project metric, I used myself. It took me six months of teaching myself as well as getting outside aid before I could take a van and begin working as an Onsite Calibration Technician. A trainee was hired on and used my training guide and was able to complete everything and get on the road within three months, a 50% decrease.

Global Broadcast Service (GBS) Antenna Replacement

Installation and testing of a new GRC-211 antenna

As the senior technician for my division onboard the USS Enterprise as well as one of the few techs onboard who was knowledgable and qualified to work on the GBS system, I played a critical role in the replacement, installation, and testing of a new GRC-211 antenna.

During deployment, the GRC-211 antenna had been damanged within the dome. The damage was unable to be repaired out at sea and on closer inspection it was discovered that the damage itself was such that the entire antenna array needed to be replaced.

I coordinated with military contractors as well as shore side work crews to coordinate the process. After getting the proper permissions, contractors were able to remove the old antenna array so that it could be lifted off the ship via crane. The company that we used to purchase the new GRC-211 array arrived and we used the crane to lift it up to the top of the mast while contractors, as well as my junior sailors, installed it.

After installation, I lead the team and worked with contractors to test the system and ensure everything was installed correctly and that the entire system was functioning as it should.

VRM Implementation

Updating and enhancing the Vendor Risk process!

Project description

To implement and enhance an end-to-end vendor risk management system complete with full automation, dashboards and reporting, as well as integrations with other ServiceNow modules. We would use a Vendor team to come in and do the build for us and our internal lululemon team would provide support and enhancements after completion.

Problem being solved

This project came about as a way of dealing with several pain points:

• Unable to track vendors who had rolled off or if they were still active and engaged with lululemon
• Not easy to track re-assessments of vendors after a year or if their scope had changed
• Historical information either didn't exist or was populated in Excel files

My Role in the Project

I worked as the business SME where my job was to ensure our requirements were being met as well as to answer questions as to how things should look and operate.

Challenges

There was immediate challenges from the get-go. I had started the project in November of 2021 and I was a little over a month into the company. Combined with misalignment, holidays, and stakeholder confusion, the project took a lot to get across the finish line. Here is a list of some of the challenges faced:

• Risk Management team not involved with vendor discussions on the project causing misalignment
• Holiday season (Thanksgiving, Christmas, and New Years), meant that many key stakeholders would not be available
• The vendor we hired had a very short time to implement a huge amount of work thus reducing our MVP into one that was not ideal
• Many of the features we requested could not be implemented due to limitations of the system
• Various requirements requested were descoped without the knowledge of Risk Management until after they started
• No design document or process flow chart completed in the beginning of the project; finally completed after the work was complete

Steps to success

Once the key challenges had been identified, the project went smoother and required the following:

• Stakeholder re-alignment on requirements
• Bringing the original requirements back to the table
• Comprehensive status reports and issuet racking.

Lessons Learned

What went well?

1. Team cohesion
2. Open communications and weekly reporting
3. Aligned expectations

What could have gone better?

1. Bringing in the appropriate stakeholders in the beginning would have prevented the majority of the problems
2. A better project plan
3. Stakeholder engagement

Conclusion

This is perhaps the most I've ever learned about project management from a project. There were so many challenges and pitfalls. Tempers were flared and expectations were smashed to pieces in what was supposed to be the delivery of an end-to-end, robust, and fully automatic platform. Instead what we got was basically a "lift and shift" of our current process from one platform to another. Granted, this new platform is much better and still address a lot of pain points, but it isn't the bright and shiny system we had originally requested.