Alex S. Moran

Work Experience (Detailed)

I've often found it near impossible to detail skills in the quick single page summary that a resume is supposed to be.  This should help clear up some ambiguity of my current and past roles and responsibilities.  This is a fairly detailed list of my skills but some skills and responsibilities are left out with respect to the more abstract aspects of my day to day experience (Examples would include troubleshooting software or defusing conflicts between team members).

Technical Project Manager

Project Scope:  I am the leading voice to set the scope and cost of a project.   Given the budget defined by either the customer or Program Management I lead the cost and technical analysis of all teams to determine if we can meet the goals.  All packages created are reviewed personally to make sure the most important requirements are met and the project is within budget. Keeping a positive relationship is a must as I may have to cut out certain cost drivers or challenge estimates in order to deliver a solid project.  

Scheduling:  I generate a schedule for the project to follow after the scope and bid has been completed.  While not exclusive, my personal favorite methods are the traditional waterfall or the more efficient agile sprint methods.  Once the staffing is loaded from the estimates I crash the schedule to determine critical path and adjust the overall schedule and resources as required.  Keeping delays or schedule advances communicated is crucial to keep everybody properly loaded.  Tracking the schedule performance index and cost performance index also helps to move resources to teams that may be falling behind.  Keeping stakeholders aligned keeps small issues from becoming major holdups.

Risk Management: As the program moves forward I have a risk register that identifies risks and opportunities for the program.  Staffing concerns, technical limitations and resource availability risks are tracked with the cost and schedule impact.  Risks get delegation plans early on and I work with the teams mitigate or defer risks.  Opportunities are tracked to add functionality or decrease overall cost. A proper realization plan goes a long way for a better product.

Change Control Board (CCB):  The CCB process starts with the review of all issues which have been identified and entered into one of the change tracking tools.  I generally meet once every week with the key players during normal development.  Using tools like Jira minimizes the number of people I need to bring into the meetings each week.  Change requests are given a priority (How important is it to the user) and criticality (How much it breaks the software) to help teams prioritize resolution of issues.  All impacted documents, software and design elements are tracked with this method.  

Status Reports and communication:  There are two status reports I provide.  The Project Management Status Report gives upper management a snapshot of how the project is doing.  This includes a quick financial summary, change request summaries, recent achievements for each team and upcoming tasks for the next 30 and 60 days.  The Team Status Report is generally a PowerPoint I put together. Knowing the material is paramount to building trust so that the teams come to me with issues found and don’t try hide something that may not even be their software (especially in highly complex systems). I cover what is critical to the teams, and tend to hold these once every two or three weeks if things are going well.  These can become more frequent as the project demands.

Document Approval:  This is a big one.  As TPM I am invested in every document that goes out the door.  I need to know the material cover to cover within that document. Process is set in place to ensure that all documents are under configuration control and nothing gets cleared if all subject matter experts have not weighed in.  I have personally reviewed, corrected and received feedback on every document for every project I have ever lead.

Software Approval:  Along with the documentation that goes out the door, I'm involved in the review and creation of software.  This is primarily through coordination with the test and software leads as well as review of test procedures, methodology and results.  The logs can tell a different story than the results if you know how to read them. You would be hard pressed to find software more scrutinized than the aviation industry. Both military and civil regulations must be followed (which are sometimes in contention with one another).

High Pressure is a Non-issue:  I thrive on that sinking pit you get when there appears to be no answer in sight. I've given presentations with armed guards at the back of the room.  I've been pulled in to support issues that could potentially ground fleets of aircraft, working late into the night to find out the cause, impact and resolution of the anomaly to keep the aircraft in the air. I’ve been in the office at 1AM for a video conference with Germany, followed by a meetings with contracts at 4 in the afternoon.  There is no issue that a bit of coffee and determination will not fix.

Software Architect

Design Approach Review:  As the Architect, it is basically my job to know as much as possible.  If i don't know the answer, I need to learn it and quick.  Primarily a pre-execution role, it's basically my job to learn the source material and determine how we can apply it to the customer's needs.  Once the material is read, a lengthy technical summary defining all the players involved, data flows, control mechanisms, etc. is laid out so that the bid team can assist with cost estimates.

Conferences:  An extension of the design phase, I am sent to conferences, presentations, and communities of practice with the sole purpose of learning everything I can to figure out a way to apply the new tools and methods I learn about in future projects.