In my last post I showed you how to handle multiple possible constraints. Today I’m going to show you how to choose your first project.
If you have all the skills and influence you need to go straight after the constraint in your company, you should go for it. Overcoming your constraint is, by far, the most effective thing you can do for your company.
Unfortunately, unless you are an owner or a senior manager, attacking your constraint directly is probably impossible. You’ll need an indirect approach where you can improve your skills, influence, and understanding of your constraint. Almost everyone will need to go this route.
Minimum requirements for your first project
Your first project must be:
- almost guaranteed to succeed
- something that your supervisor or boss will endorse and support
- related to your current role
- offer real value (high return on investment)
What are we talking about here? Well, you need to build a track record of success if you want to build your influence. So you should choose a project that is almost guaranteed to succeed. You shouldn’t work on anything without your boss’s approval. But approval shouldn’t be hard to get if your project is small, related to your current role and has real value to your company.
It would be great if your project also moved you in the direction of your constraint but that’s not strictly necessary for your first project.
You should have no trouble finding a project that meets these requirements. Everyone I’ve ever worked with had a giant wishlist of things they would love to change about the software they used. Of course, not everything on people’s wishlists are appropriate for your first project but I’m just saying that every company has a huge pool of things they would like to do or change and many of those things involve programming or IT. If you can’t come up with a good list of potential projects on your own, just ask around.
Note: you are probably on the right track if you feel that your project is the best possible use of your time.
Factors to consider when selecting your first project
Keep the following factors in mind when you are selecting potential projects:
- it’s easier for you to do something than it is to get someone else to do something
- it’s easier to spend your time than it is to hire someone specifically for this project
- it’s easier to spend salaried time than it is to create a new capital expenditure
- it’s easier to deal directly with the decision maker than it is to work through an intermediary
- it’s easier to do something reversible than it is to do something that cannot be undone
- it’s easier to do something that can be implemented incrementally than it is to implement a huge all or nothing solution
- it’s easier to do something you’ve done successfully in the past than it is to do something new
- simpler is better than complicated
- sooner is better than later
- quick implementation is better than slow implementation
- fast results are better than slow results
- safe is better than risky
- cheap is better than expensive
- changing something physical is easier than changing a policy
- profit increasing projects are better than cost reducing projects
You definitely want your first project to be on the easy/cheap/simple/quick/safe side of the equation. That’s where the big wins are and the risks are the lowest.
Beware of loser projects
The decision makers in your organization equate your value as an employee to the value they assign to work they see you doing. I hope that’s not a controversial statement.
All organizations seem to have projects that have very little value in the eyes of the decision makers. These are often ‘volunteer opportunities’ and you should avoid them like the plague. Organizing the company food drive might get you brownie points for being a good human being but if the decision makers in your company see it as a distraction or triviality, its a loser project.
Another kind of loser project is a project that offers little to no business value. The biggest loser project that programmers like to pitch is the giant rewrite of the code base. There may be very valid reasons to rewrite your code base but the cost and risk are so great that it rarely makes sense. And you should never pitch a rewrite on a whim.
Avoid the loser projects is all I’m saying.
An example of one of my early projects
I don’t remember any of my first projects because it’s been so long since I was a new hire but let me tell you about an early project I did that became a stepping stone towards my company’s constraint.
This was years ago and I hadn’t heard about the Theory of Constraints yet but I was working with some similar ideas. We had just hired a new general manager for the e-commerce division of our company and I was orienting and familiarizing him with our business. We were both throwing out all kinds of things that we wanted to do to stimulate growth in our division.
Over time we organized our ideas into several themes. One of those themes was that we lacked basic information to help us make good decisions. Our ability to generate reports or export data from our database for analysis was very limited and most of the data we could retrieve was at a very high level. So our problem was that we didn’t have the data we needed to make profit maximizing decisions.
I gave the problem a lot of thought and decided that solving the whole thing was impossible with the resources we had at the time. But I thought I could probably solve a little piece of it and make our lives better. I looked at all the data we wanted and decided that I could make the most impact by writing a script that could take data from our database and generate charts that show the cumulative sales of each product we carry over time with a year-over-year comparison. We could use this data to help us make better decisions in several important areas.
I pitched the idea to the general manager and he loved it.
Here are the details of my pitch:
- The information we want is almost impossible to generate by hand. No practical amount of number crunching in Excel would give us the information we wanted
- so I told him I’d like to write a script that can take raw data from our database and generate a chart of revenue over time for each product we carry with a year-over-year comparison
- we can use this report to help us make data-driven decisions about issues t, u, v, w, x, y, and z [the details aren’t important to this story but I believe I listed all the circumstances in which the new report would be helpful to us]
- we can run the script as often as we like to generate charts with our latest sales included
- I can generate the report in a few minutes
- it will take me about a week to write the completed script
- we can expand the script to include more data in a future iteration
We put the project on my schedule and I implemented it.
I wrote a PHP script to export the data from the database as a csv. I wrote a python script to read the csv file and generate the report. I used the pandas and matplotlib libraries to do the heavy lifting. The first iteration of this report contained about 150 pages of charts (see below). It was simple and it worked great. We used the report for all the use cases I presented in my pitch and we also found some other uses for it that made it even more valuable.
We invested one week of my time to give ourselves a tool that we’ve used for years to help us make decisions involving millions of dollars.
Here’s a sample chart:
Success begets success
The general manager was so happy with the outcome of this project that we decided to tackle a few more projects along the same theme. These were all small projects outside of my day-to-day responsibilities. We formed a great working relationship while we worked on those projects and we’ve done some pretty amazing things together to improve the business. I introduced him to the Theory of Constraints and we’ve been chipping away at our constraints for the last couple of years. I now spend more than 25% of my time working on high value projects that are outside my traditional role as a computer programmer. And I couldn’t be happier.
You can conduct a detailed analysis and try to pick a perfect first project. But my recommendation is to just make sure that your idea meets the minimum requirements for your first project and that you are generally pointed in the right direction. Then develop a pitch, pitch, and see what happens.
In my next post, I’m going to show you how to pitch your your first project. Stay tuned.