The first installment of this series discussed where your effort falls on the scale between Class of Service vs. Level of Effort.
In this installment we discuss where NOT to make cuts and why! I started writing this series in response to the sheer repetition of the questions I am being asked from clients new and old, who are suddenly stricken with a desire or notion of branching off into some kind of amorphous new media, interactive project:
- How much will it cost?
I kick off the conversation they same way I always have, targeting the 3 buckets of information I need ‘to fill’, in order to kick-off a basic requirements gathering session.
– What is the product you want to develop and why?
– What are your goals? What is this product supposed to achieve?
– Budget: Do you have a budget and how long can the effort be sustained, as is, today. (And how do you plan on getting additional funding if required, where is the ROI coming from)
These are the 3 primary threads of conversation that support the skeleton of a plan that I need to give an estimate. of course, I rarely ever get a straight answer to anything I ask, usually I get an email that says something like:
- “Don’t worry about what it is, I just need a price…. It’s Facebook for the Enterprise”
- “We can’t even start thinking about getting a budget until we know what the budget needs to be… It’s a pay-per-view mobile video app for iPhone. You know the deal!”
- “I just want to know how much it’ll cost to build out a platform for video on steroids with tweets” Hey, this isn’t Holly’weird, give me some information I can use!And then I am asked to give up a number or a “guesstimate”.
… This is where the average PM gets thrown off the track (or under the bus) – the prospects do not want to commit to the real number at the start of a venture with the financial climate the way it is, yet on the developer side every one wants to get the contract and is willing to take cuts in order to get that signature, the commitment to pay. You will spend a good deal of time, unless you keep something handy that you can just re-purpose (which is of course what I do having worked on so many projects by now) – at this point it is extremely important to keep the requirements and needs of the project in focus – if you are the client, I will not haggle and if you are the PM on another project, don’t let a client drive you!
Stay focused on what you MUST have in order to have a successful relationship with a client and a successful product at launch. Do not confuse the product with the project. I will get into the differences in more detail in a separate installment, however this is where you as client or PM are setting the TONE for how the project will be executed and setting the level of expectation on what will be delivered.
Budget Hackers usually target two areas – the two most important task related streams of effort on any project:
- Project Planning:
Why do you need 300 hours for Planning?
I should not even have to explain why this would take three times that amount, but clients these days usually feel that planning should be free or take just a couple of hours – when all hell breaks loose and the fingers start wagging, everyone will ask why things went wrong? A key ingredient of the Planning phase is requirements gathering and building out the scope of the project – these are all documents that need to be signed, reviewed by lawyers depending on the scale of the project and agreed on by all parties.
More planning leads to better planning and better, fluid processes that have been fully rationalized are then put in place. To get multiple teams on the same page takes time, resources and a lot of administration on the Project Managers part to get everyone aligned and resources allocated before the project begins. A poorly organized project will result in a poor product. Do the math and you will see it is worth the additional bucket of hours for human time to get it done correctly – Unless you plan to fail.
- Quality Assurance testing:
Why do you need 120 hours for QA?
Quality Assurance testing happens over time and is a responsive, team effort – as we ready a product for launch we will find issues along the way. Every step forward needs to be done very carefully, needs to be documented and then tested, reviewed and approved.
During QA, the developer will attempt to correct issues as they arise and then the tests begin again. If you do not have a QA team doing the testing, the bug reports will come from the clients, and that is not only embarrassing but deeply diminishes the odds for survival of a new product.
Something as simple as changing the header navigation on a single page, if it wasn’t planned for, can cause a lot of extra effort and will leave the final product vulnerable to bad exposure if it isn’t handled correctly after the decision to make a change has been issued. New media applications have multiple feeds of information and administration that will need to be upheld after the product is launched and thriving – this living creature needs to be feed or it will just stop! QA also helps the PM help the owner of the new product rationalize what long-term resources s/he will require to keep a successful site going and scale it out as needed.
If you are planning on making that first big step, you need to be prepared to learn the language and let the experts do their job… Let me know your thoughts!
Leave a commment below.
More valuable insights to come in future up-dates in this series on Budget Hacking and New Media Planning – the next installment will discuss the “Blended Rate” and how this can work for you to keep costs down and quality high!