Balling without a Budget

My company is notorious for running almost all small and some medium size projects without an “official” budget or with no mention of budget at all.  Many of these projects are either product developments or internal process improvements.  Upper management believes that these types of projects shouldn’t be limited to the constraints of a budget primarily because a successful new product or major process overhaul is invaluable to the company and they want our Engineers to have freedom when doing their “thing”, whatever that may be.  Major costs are approved/denied by the management team and these costs are recorded throughout the project but no one sets a limit.  Management also believes, rightfully so in some cases, that the team will eat up a project for a budget even if it doesn’t add any saleable value to the end result.

I’ve seen this work exceptionally well in some cases.  The most prominent was the recent development of a new product for the automotive market.  The project team successfully completed the development with total hard costs of ~$150k.  By the end of this year we should accumulate ~$100M in cumulative revenue from this product.  Winning!  If we had set a budget for this development my guess is that it would have been in the $2-3 million range given the scope.  This project was particularly interesting because the development team took “no budget” as a challenge to keep the project costs as low as possible.  This allowed the team to come up with some really creative solutions to the more challenging aspects of the development.  There was a very respectable amount of reuse of existing automation equipment, never before seen manufacturing processes, and they leveraged a significant amount of existing raw materials.  Give these guys a raise!

On the other hand I’ve also seen this philosophy blow up in our happy little budgetless faces.  We had a team start developing software for order entry, marketing, and other internal processes.  Here we are many millions of dollars later and we have nothing usable to show for the development.  This team took the “no budget” philosophy as an opportunity to try and reinvent the wheel despite the fact that we’re not in the business of selling wheels.  Plus, square wheels don’t have much use in the world we live in.

I have a couple of questions that I’m hoping my top notch MBA classmates and friends may be able to help me address.

Can you think of situations where budgets may be detrimental to a project development?  Are there, or can there be, guidelines established on which types of projects require firm budgets and which can be looser from a cost standpoint?  Or, in your opinion, do all projects need a firm budget, period?

Can you determine during your hiring process which PMs are “budget eaters” and which ones would take the “no budget” project plan as a challenge to keep costs low?  How can we go about identifying these distinctly different personalities during the interview process?

My (Limited) Experience with Project Management in My New Role

There has never been a better time for me to take a Project Management course than right now.  I recently moved into a senior management role for the only separate business unit within my company, Critical Products and Services.  It took just a few days for the honeymoon period to be over and for the issues to become apparent.  Many of the core issues boil down to improper or nonexistent project management and my hope with this post is that some of you may learn from our, and my, mistakes.

Proper Project Management needs a proper Project Manager.  Most of the projects that existed within the business unit exhibited a “laissez faire” project management style, which is a nice way of saying none at all.   Everyone on every project was the PM for their own contribution.  We had dozens of “Chiefs” and zero “Indians”.  This style can occasionally work on minor projects when everything’s running smoothly, but when it hits the fan all hell breaks loose.  Nobody, even the perfect PM, “wants” to deal with the tough problems, or ask the tough questions, and if a go-to PM that’s accountable for the project doesn’t exist, no one will.  If no one steps up the project fails, period.  I learned quickly that every real project needs a clear leader, a clear communication path, and a clear route for dispute resolution.

Project Management needs to be standardized.  We had 4 PMs in our unit using 3 different PM software platforms.  In and of themselves these platforms can be very effective.  When mixed together the result is a colorful pile of uselessness.  The tools that are used by the PMs and by the teams need to work together seamlessly across the board, otherwise they will be completely ignored and the time spent putting together the project plan was more or less wasted.  Team members neither have the time nor the desire to learn multiple platforms and if a PM is on vacation or traveling good luck finding someone willing to help out in a different software platform while working on their own projects.  Last week we started the implementation of cloud based “teamwork” platform Asana.  The platform is simple and easy to learn but more importantly it’s able to integrate with all types of helpful tools like Instagantt, Google Drive, and Salesforce ultimately making it seem like an effective online solution to our PM standardization issues.  I guess time will tell but at least we’re moving in the right direction.

Last, but certainly not least, Project Management is incredibly difficult.  It takes a certain type of person with thick skin and incredible willpower; great PMs are very rare.  I know am not a great PM, but I hope to be one day.  It takes an amazing amount of patience (you guys know that’s not my strongpoint 🙂 ) and attention to detail to coordinate a difficult project.  Know yourself, know your team, and use each member efficiently and effectively.  Most importantly, never stop communicating with each other.


The exciting nightmare that has been my life for the past 8 weeks.