HireThisGeek.com

Program/Project Management

Ideal experience

I have over 20 years of project management experience and roughly 10 years of program managment. My work is highly informed by my years of doing programming, system administration, QA, and the other varied tasks needed to complete a given project.

Program Management

Business Operations Program Manager
As Business Operations Manager, I determined what the overall business needed, and the best way to execute on each of the needed projects. I got buy in on the plans and built what was needed with my team. I pushed the each of the planned project from both a high and low level. This work directly helped the organizations to be more mature, healthy, and data driven.

Program Managing the migration to AWS
Program Managing the project to migrate Vindicias offerings from a datacenters to AWS, required coordination of many teams throuout the company both in building what was needed, followed building and helping ot execute the detailed cutover plan for staging and then production.

PCI and SOC audits
Program Managing the Vindicia audits was far more than just making sure we passed the audits. Rather, I put systems in place to cover everything needed. For every part of both the PCI and SOC audits, I made directions or diagrams to make things clear as can be. Each audit requires me bringing in the heads of each department to cover the parts of the audit that relates to them and their groups. Passing the audits was required for the company to continue to operate, so the stakes were hight, and building a more solid system put the company on a more solid foundation.

Project Management

Each time that I'm doing a Program Managment job, I'm also doing Project Managment as part of that work.

Scrum agile methodology is kind of the default way to run a project these days, along with Kanban. I've spent years project managing teams using the Atlassian tools.

I enjoy writing specifications, making timelines, getting buy in, and helping to clear blockers of any type. I like to keep everybody in sync, on schedule, productive, and happy.

I see out critical feedback and consider it vital. Retrospectives are of course and essential part of doing agile projects.

I am extremely communicative and goal oriented. I'm dedicated, reliable, and my enthusiasm tends to be contagious.

I've project managed teams that were widely distributed around the world as well as teams where everybody resided in the same building.

I'm self driven and tend to ask higher managment the questions they want to be asked.

Project management methods

Below are some of the ways of managing projects I have found helpful. These concepts have worked for me with big teams, small teams, local teams, distributed teams, agile methodology, and waterfall methodology.

• Agree on what we're building: Give serious thought to what you're building and define it before starting true development. One of the main dangers with agile development is that this is often not given enough consideration. This is not the same as insisting on the traditional waterfall method. But it does mean that you should not start building something until you have a good idea of what it is that you're building. Everybody on the team should have a had been given a chance to proof the plans, talk it through, and give their input.
  • Compact releases: It's best to make any one release as slim as possible, especially the initial release. More features can always be added later. An initial release should have the minimum features possible. Determining what is being built needs to be worked into the project timeline. As the saying goes, "Release early, release often".
  • Don't reinvent the wheel: Build based on previously existing and reasonably mainstream tested and proven technologies.
  • Design for maintainability: Writing basic documentation and adding comments to the code need to be worked into the project timeline. Projects should be designed such that they can be maintained by new programmers.
  • Use "Best Practices": Regardless of what technology we are using, it's vital that we know what the best practices are and that we abide by them as best we can.
  • Peer review = good: If any given piece of work is only viewed by one person, then there should be more reviewing. When one person reviews another persons work, it's fine if a quick pass is taken. But second opinions should be the rule of thumb. It's also vitally important that this always be done from a cooperative supportive viewpoint.
  • Give people a say on what they are building: Everybody who will be involved with the implementation should also be able to give input on what is being built. Completely separating the role of the designer and the role of the programmer tends to be a mistake, unless the programming is planned to be "code to spec" (such as is often asked for with offshore coding). Note that accepting input from the team needs to be done efficiently, and with an stated expectation of only making those changes that are of real value.
• Agree on the timing: Everybody involved needs to feel comfortable with their part in the project.
  • Deadlines are good! They are vital for getting things done. Lots of little deadlines are better than one big deadline. It's important to encourage a culture where people make their deadlines and take pride in doing quality work on time.
  • Consensual time estimates and deadlines: The people doing the actual implementation will be the best at determining how long a given task will take. They will also be more willing to work hard in order to make a deadline that they themselves helped to set.
  • The release date is a sum of the parts: Some tasks can be done in parallel and others can't. The release date is determined by adding up how long it will take to complete all of the tasks that need to be done given the available resources. To go for an earlier release date, adding resources can sometimes help. But generally reducing the features in a given release is a far more realistic way to get a release out on time.
  • Padding: Know that most people at any level of a project are overly optimistic as far as time estimates go. If the customer needs to have a working product by a particular date, the internal date for that deliverable should have good padding and should ideally include time for testing and fixing issues found by testing. Using agile methodology and story points can over time help to make productivity far more predictable.
• Extreme visibility:Everybody who is working on the project should have a clear picture of how everything fits together, and an idea of the timing involved in the project.
  • A chart of the timing + dependencies: It's not hard to make Burndown chart or a Gantt chart or that shows the timing in a way that anybody can easily read. Using a Burndown chart for the short term goals makes sense. Using a Gantt chart for the big picture is also wise. It's easier to reliably hit deadlines that are a week away than it is to hit deadlines that are six months away. Long term planning is a tricky thing. Don't minimize the risk. We must regularly work to validate long term time estimates.
  • Make sure everybody sees the big picture: Everybody should understand how their work fits in with everybody else's. People do a much better job of making deadlines and doing the correct work when they know how all the pieces fit together and how each of those pieces are progressing.
• Ensure motivation: It's partly the job of the project manager to keep everybody excited about what the team is building.
  • Happiness = productivity: Different people are motivated by different things. Putting food on the table is important, but it is only  one of the potential motivating factors. It is hugely beneficial to be aware of what helps the different people on the team to be inspired to do great work. A healthy, functional, and sustainable environment is essential.
  • Retrospectives: It's not about blame. It's about avoiding making the same problem again. When deadlines are not made, we find out why, and learn from the past. When there are problems, we brainstorm to find a way to avoid similar problems next time.
  • Celebrate success! It's worth making a fuss when things go well and when deadlines are made.
• Meetings: Meetings are vital, but they are also very expensive. If a weekly meeting has 10 participants and the meeting lasts an hour, the cumulative cost of that meeting, including all salaries, is nontrivial. I believe in running meetings with an eye to ROI. Here are some of the methods I've come up with for doing this.
  • Daily standups: A well run daily standup as an example of an ideal meeting. It's short, efficient, and everybody participates.
  • Hold regular efficient meetings: Consistent meetings are key. Know that meetings are also very "expensive". You don't want to spend anyone's time without good cause. It's critical that meetings be run in an efficient way.
  • Anticipate the problems & resolve them before the meeting: If there are 10 people in a room and a problem can mostly be resolved via a discussion with two or three people, consider doing that before the meeting. I often try to resolve as many of the main issues is possible before the meeting starts. Inevitably, there are still critical things that are talked about at the meeting. But the chances of later requiring several meetings to resolve the same issues are substantially lower.
  • Send out an agenda: Before the meeting, make a clear list of what's being covered. It's okay if other things are also discussed, but having an agenda and structure to the meeting helps everybody.
  • Send out what was resolved: After the meeting, send out the notes saying what happened.
  • Shorter is better: I'm a big fan of fast paced short meetings. Sometimes just a few minutes with the right people can solve the problem at hand. Often meetings that are an hour, should instead be half an hour.
  • Reduce the number of people in a meeting: If a person is not actively participating in a reoccurring meeting that they are attending, maybe they don't need to be there. When I see this happening, I'll talk with the person to see what value they are getting out if it, and often they choose to opt out of the meeting. Notes from the meeting can disseminate the information. In some cases, I meet with that person after a meeting to give them a short update on the issues that relate to them.
  • The basic principles: Traditional meetings can be remarkably inefficient. People sit around and listen to other people talk, often about things that don't directly affect the listener. That's the reason people don't like meetings. When run properly, everybody at the meeting is actively participating. As far as Return On Investment for the company (and the satisfaction of everyone involved), this is a goodness.
• A few basic rules: This repeats some of the things discussed above. But some of those things are worth repeating.
  • Release early, release often: Engineer in small phases where ever possible.
  • Extreme visibility: Make everything pertinent visible to everyone.
  • Meetings: Keep meetings as short as possible. Keep meetings very efficient. Follow best practices for meetings.
  • Small teams: Keep development teams small.
  • Time estimates: Time estimates come from the bottom up. The person doing the work gives the estimate on how long a given task will take.
  • Testing: Integrate testing into the development process.
  • UI Testing: Do UI testing and get your end user feedback early as possible and as often as possible. Doing UI testing with something as simple as a print out is okay if it speeds up the process.
  • Protect your people! Protect the project and people doing the work from the interference and over involvement of management if needed. Clear blockers for your team. Keeping the team productive is key above all else.

Some sample projects

Implement Rearchitecture - Migrating Vindica offerings from datacenters to AWS

Problem: Vindicia processes millions of credit card transaction for various events, including highly public sporting events where the transactions per minute can be staggering. On-prem datacenters drastically limited how quickly we could scale up for large events.
A rearchitected system needed to be built. We used standard scrum methodology. 

Solution: Used traditional scrum methodology with 2 week sprints. Mapped out the full project ahead of time with deep involvement from the highly skilled team. Each sprint got completed with the work planned, and the entire implementation was done on schedule, including testing.

Cutover - Migrating Vindica offerings from datacenters to AWS

Problem: The operations and Vindicia product offerings had been re-architected, but cutting over from the physical on prime data centers to the new running AWS system, including a database switchover, was a vital and nontrivial task. With the business that's doing millions of credit card transactions regularly, every second of downtime counts. And risks need to be alleviated as much as possible.

Solution: I made a Google sheet checklist which itemized each step needed, including validation. I had a large number of small meetings to validate and refine each step. Each step was tested with a live system. Anything that could be done to make the transition less risky or faster was done. The spreadsheet showed every persons backup, every persons contact information. Rollback plans were made. Each step was listed with timing and an easy checkbox to check, along with conditional formatting to mark the line as done and then verified. The sheet included a tab for what specific people were on call and working around the clock for the next week. Nothing was left to chance. The migration was not simple, but the exhaustive planning paid off beautifully and the staging cutover went well, latter followed by the production cutover.

Key-O-Matic

Problem: All licenses were being hand generated.  Turn around time was slow.  A large team was required to handle the requests.  Customer satisfaction was low and errors were common.

Solution: I project managed and was primary programmer and designer of a web and email based tool to automatically authorize and distribute permanent and temporary licenses for internal and external use.  Key-O-Matic generates licenses for multiple licensing mechanisms, multiple computer platforms, over 100 products, and for multiple countries.  Evaluation license durations, number of licenses, and marketing letters can be customized by product.  Both web and email forms are easy for customers and license administrators to use.  This tool has vastly improved accuracy, efficiency, and customer satisfaction. It has been in production since 1994 and is still being used by customers today. This was the first system to automatically give out software licenses on the web.

Sales Order Download

Problem: The downloading of sales orders into the support database was failing a high percentage of the time due to numerous data errors caused by a variety of sources.  For years this quagmire had been directly affecting support revenue and customer satisfaction.

Solutions: Reduce the percentage of sales orders with errors by over 90%. Vastly improved and clarified the error checking, by breaking errors into distinct "buckets".  Created drill down reports that gave a clear view, from a high level overview, to the low level details of a single sales order.  Got buy-in from throughout the company until every error bucket was owned by a particular responsible group.  Groups also agreed on which team was causing each problem and agreed to work together on implementing solutions.  Automated the reprocessing of sales orders.  Created a system to fully manage the backlog of problem sales orders.  Reduced the percentage of errors dramatically.  Automated the correction of many types of errors. This was a huge win for the company! It resulted in much happier customers.

Contact Julian

Get in touch and chat about your company or project.

Julian Cash     415.738.9385     julian@HireThisGeek.com or see the contact page.