Software Development Project Manager

projectmanagement

What I do

My responsibilities include the prioritization and scheduling of task assignments from the general office business users,  field associates and our customer-base to streamline task completion, remove obstacles, and increase productivity.  Basically, my job is to remove all the hurdles that prevent programmers from programming.

How I Do It

My job is to remove all the hurdles that prevent programmers from programming
They key to increase productivity and efficiency is information.   You can’t manage what you don’t measure.  All my staff are required to send me weekly updates with the status of all  their current task assignments.  However, if something comes up during the week that will cause an obstacle to completion, we intervene immediately to shuffle task responsibilities among the developers and re-prioritize as necessary.

Whenever I am assigning a task, I gather as much information as possible regarding the specific requirements so I can determine which developers will be needed, how many developers I can assign, what other tasks will be impacted by the assignment, and a rough measure of time to completion.  It’s also important to know how the task aligns with the overall objectives of the business.  Is it going to increase revenue?  Cut costs?  Close a compliance hole?  There are even political implications that have to be considered when assigning a task.

You also have to remember that not all developers are created equal.  Some excel at newer technology, some handle the older technology.  Same goes for the type of task assigned.  You can’t simply assign any old task to any old developer.  Each person has individualized and created their set of specific skills that they excel at performing.  Another factor to consider are their personalities.  Some work better alone, while others thrive in groups.  Some can take a task to completion with only a general overview and some guidelines, while others need to have the specifics spelled out for them.  Each type has it’s pros and cons.

Regardless of all the factors involved in task delegation and assignment, the most important factor is communication.  Your organization is constantly making decisions that effect the path the company will take into the future.  It’s important to communicate accurate estimates to completion throughout the task workflow process.

Significant Projects I Have Managed

While there are hundreds of tasks a year that come in under my area that I am responsible for researching, assigning and making sure they are completed in a timely manner, there are some tasks that are so large that they involve multiple developers and require multiple months to complete.  When you encounter these caliber of projects, having an exceptional project manager really makes an impact.

Here are a few I want to share with you.

Office365 Email Migration
Sarbanes Oxley – SOX Compliance
Pricing Transformation
Procure to Pay
Key Performance Indicators
Truck Finder
Tire Pressure Monitoring System
Web Order System
Call Center Software
Document Imaging and Indexing


Office365 Email Migration (2014)

To align our efforts with Goodyear’s “One Team” efforts, we have recently completed a successful migration of our email systems from our POP3 hosted environment to a fully-collaborative cloud-based Microsoft Office365 platform. This required a lot of team-based collaborative efforts to make sure the migration was smooth while also changing several systems to mass update email data from the old email addresses to the new ones.


Sarbanes Oxley – SOX Compliance (2011-2013)

I implemented I/T task system tracking and created the systems to provided documented evidence to support our organizations efforts to stay in compliance with SOX. As part of this project, I actually performed the SOX testing myself so I could develop a deeper understanding of what is needed from a testing standpoint.


Pricing Transformation (2011-2012)

Our previous pricing structure revolved around a “Cost +” method.  Starting with the item cost, the price is adjusted and set at various factors above cost.  While this always ensures you will make a profit on what you sell, it doesn’t take into consideration market conditions, product availability, order quantity and frequency, and other various factors.

The biggest challenge for this project was the compressed time-frame given by management to institute the change.  We were notified in October that the changes would need to be in place by the end of the year.  Quite a feat considering the magnitude and multitude of changes that would need to be instituted to affect the way pricing is managed throughout the entire system.  It’s not just about how you display the price on an invoice.  It’s a bottom-up approach affecting all pricing.  From the way it is managed, how it is applied to specific product groupings, commission paid to sales reps, applying marketing and discounts, etc.

Obviously, with such a reduced time-frame, the ideal solution was not one-in-the-same as the optimal solution.

First, I had to get an understanding of the depth of the changes involved.  First, I met with the consulting firm that had performed an extensive analysis using data we had provided months earlier.  The proposed changes were massive.  It would require completely new pricing subroutines to be created and maintained.  Also, management had decided that they would only apply this new pricing structure to a subset of our products, which meant the old subroutine would need to co-exist with the new one as well.

Next, I met with my team to determine who all would be involved in the changes and started them researching the various programs that would need to be changed.  Sometimes research is a task all in itself and regardless of how well and long you research, you have to remember that projects of this scope tend to impact areas you hadn’t anticipated either.  You have to build in some leeway on your project estimates for these unaccounted for discoveries that happen last in the project implementation.

At it’s core, the pricing transformation used could be applied to any product and market.  Using the data regression analysis they provided, we were able to apply various factors consisting of the following:

  • Competition of like-businesses at the specific location where the product is being sold
  • Quantity of product purchased in a single instance
  • Frequency of invoices to a customer
  • Previous pricing history to a specific customer
  • Total customer spend by customer
  • Percentage mix of product purchasing history

Each of those factors could then be further affected using various bands.  Basically, to sum up the end-result of the pricing given on an invoices, you will get the lowest price when you sell a lot of your best products to your biggest customers, often, in a crowded market.


Procure to Pay (P2P) (2011-2012)

While our home-grown point-of-sale system has an excellent tracking mechanism for inventory items, such as Tires – it lacks the ability to track non-inventory items in any way (think toilet paper, pens, paper, and other general office supplies and services,  etc.).

We knew we wanted a better way to track and manage those types of items, so we first set to putting together an analysis on what it would take to expand our current system to support it.  First, we met with management to determine what features would be most important to them when implementing such a system.  Then, I assigned a developer to put together a very detailed estimate on what it would take to build the system from scratch.

While the in-house development was being researched, we also started  conversations with various 3rd party vendors to see what they had to offer.  Initially, we setup various webinars and demos to weed out those that obviously didn’t have the specific requirements we were looking for in a procure-to-pay system.

Detailed notes were taken at every stage to ensure that we were measuring each of the vendors against the same set of criteria.

Once the I/T research was done and we had met with all vendors, we met with management to determine whether we would write the system in-house, or purchase an outside system.  Due to the extensive feature-set required and the time it would take to implement such a system, it was decided we should integrate with one of the 3rd parties we had interviewed.

There were two major factors that played into that decision.  The first was that due to the long development time estimated to do it in-house, we felt that the longer the compliance-hold stayed open, the longer it would put the company at risk for losing money.

The other factor was the cost of tying up a developer that could otherwise be working on other projects that benefit the company outweighed the cost of purchasing and integrating with one of the vendors.

Once the decision was made to go with a 3rd party, we narrowed our focus down to the two that we felt best represent the needs of management, and the I/T needs of integration.

We brought each vendor to our corporate headquarters to give in-depth demos of all features and functionality of their products as well as requested detailed cost-estimates for the product, services, and integration.  Determining the TCO was key in making sure that we were comparing apples-to-apples.

Several additional rounds of cost negotiations then took place before we finally settled on a vendor.

To sum up the vendor selection process:

  • Make sure you meet with management to determine their key requirements and what features they consider as a “nice-to-have”.
  • Meet with as many vendors as possible and rely on the experience they bring in their fields.  There may be additional pieces of information they bring to the table that have not been considered.  You also need to weed out those that do not meet your key goals and requirements.
  • Make sure their I/T integration methodology matches up with the available integration methods your company supports, as well as those that match-up with the knowledge-base and expertise of your available developers.
  • Everything is negotiable – don’t be afraid to ask for off-the-wall or non-standard requests.
  • Nail down how training and post-integration support will work.
  • Do your homework.  Are these vendors planning on being here for the long-term?
  • Perform a like-comparison.  You need to make sure you are measuring separate vendors on a common set of criteria.

 


Key Performance Indicators (KPI)  (2010)

Tracking the Key Performance Indicators is something that should be done at any company, regardless of size.  However, once your company is big enough, you’ll begin tracking all sorts of data points you most likely hadn’t anticipated.  Our old system for tracking these was a cumbersome, time-consuming process that involved various nightly batch programs that had to be written, various changes to our production web system to pull and display the aggregated information that was being build at night and had very limited overall usage.

When I decided to rewrite the system, I had several goals in mind:

  • Fully Dynamic – I wanted a system that would allow us to track anything, group anything
  • Consistent Design – In order to better measure the results being delivered, I wanted to deliver a more consistent view of the data so you could compare one data point to another and know that you were comparing apples-to-apples.
  • Bells & Whistles – As long as you are rewriting a system, you might as well make it everything it ought to be.  I had been compiling various feedback over the years of what the system should (and shouldn’t) do, so I had a nice list to pull from and implement.

Fully Dynamic

The first piece I tackled was a rewrite of the COBOL batch programs that processed the data nightly.  Our IBM Mainframe had come along way since the initial implementation and we were now able to implement several pre-fetch SQL statements which allowed for the dynamic pulling of SQL text from a table, and then render it against the database.

However, not all KPI are created equal.  So, there were various pieces that needed to be built to align specific indicators into groups.  I could have written it all in a single batch program, but instead I decided to write several so that each program would align with the way the indicators were being built.

I also had to create a new normalized table structure to hold all the new data points.  Normalization is key when creating dynamic systems.

Consistent Design

I knew I wanted to present the data in a more up-to-date fashion.  At the time, we had settled on the Yahoo YUI as our JavaScript framework, so I was able to quickly get a template up and running of how I wanted everything laid out and how I wanted it to work.  Tabs across the top for each logical area or department, then functional groups inside a tab for closely related indicators.

Another piece I built in was the ability for a KPI to cross boundaries.  That allowed a indicator to reside in both a “Sales” tab and a “Overall” tab.  Great for reducing the amount of work needed to show an indicator, while also allowing multiple sets of views to be created for specific reasons.

Also, because each indicator now acted the same across boundaries, it was easier for the users to understand and make use of the data being shown to them.

Bells & Whistles

Our previous application had no way to allow users to setup a KPI.  There were also no automated graphing tools to visualize the data.  Printing was clunky.  Security was all or nothing.  The new system conquered all those limitations while also reducing our CPU costs for the KPI system overall.


Truck Finder (GPS-based Vehicle Tracking System) (2010)

Truck Finder was the first project developed by Wingfoot to shift I/T focus from a cost-center, to a profit-center.
The goal was to create a value GPS tracking solution to market to small commercial tire servicing dealers and small independent commercial fleets that typically can’t afford a full-blown satellite-based tracking solution, such as QUALCOMM.
I managed a small team of developers throughout the project – starting at the projects inception during the research phase, all throughout development, and deployment. I also presented the solution to the Goodyear Sales Force and Dealer Network at the Goodyear National Conference in January 2011.
Truck Finder was implemented on-time, and on-budget.
Portions of the business process have been submitted for patent (Application Number: 61436413).


Tire Pressure Monitoring System (TPMS) Software (2007)

 


Web Order System (Custom-Built Shopping Cart) (2006)

 


Call Center Software (2005)

 


Document Imaging and Indexing (2004)