HireThisGeek.com

Project Management

Ideal experience

I have over 10 years of project management experience. My skill as a project manager is highly informed by my years of doing programming, QA, and the other varied tasks needed to complete a given project. I specialize in LAMP stack web development.

I enjoy writing specifications, creating timelines, and easy to understand Gantt charts. I like to keep everybody in sync, on schedule, productive, and happy. 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 highly distributed around the world, offshore programmers and testers, as well as teams where everybody resided in the same building.

Project management methods

After project managing with a wide variety of teams, projects, and companies, there are a number of methods that I find will help to assure success.

• Agree on what we're building: Changing specifications partway through project can easily make the project take several times longer. Unless we are specifically going for 100% agile development, the more that gets figured out up front, the better.
  • Compact releases: It's best to make any one released, especially the initial release, as slim as possible. 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.
  • Don't reinvent the wheel: Build based on existing reasonably mainstream 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 are realistic and can be maintained by new programmers.
  • 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 needed with offshore coding). Note that accepting input from the team needs to be done efficiently, and with an 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, add resources, or better yet, reduce features.
• 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 a Gantt chart that shows the timing in a way that anybody can easily read.
  • Regular meetings: At least once a week, possibly more often, there should be meetings where the progress is discussed. These meetings should be efficient and reasonably short. As many issues as possible should be resolved before the meeting.
  • 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.
• Motivation: It's partly the job of the project manager to keep everybody excited about what the team is building.
  • A paycheck is only part of it: 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.
  • Learn from difficulties: It's not about blame. It's about avoiding making the same problem again. When deadlines are not made, find out why, and learn from the past. When there are technical problems, 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.

Scrum/Agile development

Since even before the Scrum/Agile movement started, I've been always managing projects with similar basic principals. For example, I have always promoted the following:

• Release early, release often. Engineer in small phases where ever possible.
• Make everything visible to everyone and have very frequent face-to-face communication.
• Keep meetings short. Keep meetings very efficient.
• Keep development teams small.
• Time estimates come from the bottom up. The person doing the work gives the estimate on how long a given task will take.
• Integrate testing into the development process.
• Do UI testing and get 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 the project and people doing the work from management if needed.

Some sample projects

TWIKI.NET Friendly Admin Interface

Problem: TWiki is one of the most popular Wiki's in the world. TWiki.org is an open source project. The initial creator of TWiki.org, Peter Thoeny, also formed the VC backed commercial venture, TWiki.net. The interface for setting up TWiki and making system administration changes was quite confusing, especially for non-technical folks.

Solution: I helped to design and also project managed a very easy to use web interface for setting up an initial installation of TWiki, and for making the most common desired customizations. This worked out perfectly for most of our clients. It was an ideal value add over the Open Source product. It also resulted in the benefit of less customer support needed per customer.

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: 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.

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 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 which team was causing each problem and agreed to work 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.

Low Cost Pull

Problem: Customers were shipped CDs of new software and software updates as needed.  There was no online solution for customers to downloading updates or view what they were entitled to.  Shipping and handling costs were high and customer satisfaction was sometimes adversely effected.

Solution: Helped to design and Project Managed the creation of a tool which gave customers access to download a wide variety of software.  Access was given based on what a particular customer was entitled to.  Customers are now able to download updates the moment they come out.  Rather than shipping CDs, the company now often just sends an email or post card.  Customers are more effectively able to manage their software subscriptions.  Customer satisfaction is improved and costs reduced.

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.