7
I was thinking about our many projects at iProv today during church. We’ve got a pretty solid process for managing our project but there are some hand-calculations that still have to be made.
As most of you know, the majority of my job is project management and new business. I can’t really teach you how to come up with creative solutions but I can talk just a little bit about project management. This blog entry is going to focus on proposal development, project evaluation, and break even points.
At iProv, we break projects into “days”. If your business breaks things into “hours”, you will have to do a little modifying.
Proposal Development
When you look at developing a project, use this formula
- $ per day = (Amount of Money You Want Your Organization to put in it’s Pocket Each Day) + (Price of an Employee Per Day * Number of Employees Working)
- Total Project Price = ($ per day) * (total number of days in the project)
Sure this is simple, but many people try to make this a lot more confusing. The “$ per day” is what the organization profits each day.
Break Even Date
After the customer agrees and signs off on the project, take a look at the start date and figure out what day the break even date is. You may tell a customer that the project will be done on January 1st. But, b/c the customer puts the project on the back burner, it won’t get done until March 1st. It’s fine b/c the customer doesn’t get mad at you but you’ve got to keep paying your employees each day. The longer the project goes on, the more it cuts into your organizations profits.
- # of work days for break even = (Total Project Price) / [ Price of an Employee Per Day * Number of Employees Working ]
Project Evaluation
After the project is done you can evaluate the project and see what your organization made after the project was complete. To do this, just reverse the Proposal Development.
- $ per day = (Total Project Price) / (Total # of days in the project)
- net profit per day = ($ per day) - (employee price per day * Number of Employees)
Good luck on your next project!
“But, b/c the customer puts the project on the back burner, it won’t get done until March 1st.”
This shouldnt affect the development time (unless I’m missing something) by your employees unless the customer hasn’t fully specified the requirements (which really should just delay the development, but doesn’t cost developer time … in a good development cycle paradigm).
These kinds of pushbacks shouldn’t hurt your bottom line too much IF you have ample enough projects to keep your employees busy even when one project gets delayed. Now, if it is the only project running, then you are correct.
I run on months… as in… the first of every month my pocket gets lighter. hahah. Also, what the fuck man? do you think about jesus while you’re at work?
Also, thanks for coming to the party, hope you had fun.
“This shouldnt affect the development time.”
Projects come to a dead-stop when customers can’t sign off on changes or if they decide they can’t make a payment.
When that happens, you can’t expect your employee to “hold off” on their pay check. And, although there will always be other projects he can apply his time toward, you have to evaluate each project independently.
And I had a lot of fun at the pool party. Even though I can’t seem to get this water out of my brain.
“Projects come to a dead-stop when customers can’t sign off on changes or if they decide they can’t make a payment.
When that happens, you can’t expect your employee to “hold off” on their pay check.”
Right, but the project costs you no more money as development has stopped (for the moment at least) and the employees should be applying their time to other projects (in theory).
If the customer’s lack of payment makes it hard for you to pay your employees in a timely fashion, thats another matter, but it doesnt increase the cost of the project as the formula you supplied states.
However, I suspect simplicity is the goal of the formula…
A more accurate “Total Project Price” would be (”Man-days” spent working on the project) * (Cost of “Man-day” + profit goal per employee per day).
The “net profit per day” FOR THIS PROJECT ONLY would be {(”Total Project Price”) - (”Man-days” spent working on the project) * (Cost of “Man-day”)} / (Total # of days in the project)
You would still divide by the # of days for the daily profit as the delay does affect it …
Pool party … you LR kids have all the fun
Right, but the project costs you no more money as development has stopped (for the moment at least) and the employees should be applying their time to other projects (in theory).
When evaluating each project independently, those employees have no other jobs to apply their time to. You’re proposed costs need to take this behavior into account but simply saying “we’ll apply our time to something else” isn’t a real solution.
Although the first calculations is “simpler”, it returns the same result.
The second calculation is more accurate if and only if the number of “Total # of days in the project” differs from the “man days”. But, as I said in my example, I’m assuming this is the only project and the number of “man days” is the same as the “Total # of days in the project”.
We’re saying the same things in our calculation with one disagreement. The disagreement is whether you assume you can apply someone’s cost to another job.
I agree …
And I know that expecting your employees to be able to jump on something else isn’t always realistic.