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?
  

  NO MORE BUDGET HACKING!

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.

  

  Plan it out now

  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!

I want to start by stating very plainly, there is no such thing as a simple web page.  Not anymore.

Consider this, interactive new media products are living organisms that will either thrive once launched – like living creatures, if they have a healthy gestation, these things can grow strong over time leading long, healthy lives – or, if malnourished or traumatized during their incubation,  will die a slow, painful death in the petri dish.  The cost of birthing one of these “organisms” can not succeed if the stake holders don’t respect the process.

It's ALIVE!

YES, I can come up with a project proposal that delivers the same basic Interactive New Media “product” for as little as $80k or up to $2.5M plus – why is there such variance in the cost?  It is very, very simple – cost depends on what I call “Class of Service” vs. “Level of Effort”.  You must have some idea of what you want before you even ask me for an estimate, start by asking yourself, who will I show this to when it is “done” or has reached “Phase I” and how will they rate the success of my project?

I can generate an estimate, an eerily close estimate, based on rationalizing two variables that I have come to know over the last 16 years of bidding projects and managing them, successfully:

Class of Service: A reasonable classification for the amount of effort that needs to be exerted in order to meet the client’s level of  expectation; variables that effect class of service delivery can include but are not limited to time to launch, target ROI and the number of resources available at a given time.  Classifications can include Enterprise, consumer ready, back-end, informational only applications to be use strictly by niche experts, etc.

~ As defined by Nico (I tend to make a lot of Networking metaphors and this is no exception – CoS )

Level of Effort: The equal amount of combined resources, planning and preparation against available budget required to deliver the “class of service” expected by the client.  i.e. If you are collecting email addresses, how many do you expect to collect, how qualified do they have to be and in what time frame?  If you don’t know the answers, you are in no position to start estimating the project.

Level of Effort is a matter of success or failure

These are very difficult times for many of us, and like many out there I only get paid when I am billing hours – a lot of time goes into the bidding process and many compromises are made to win bids – but fair is fair.  When you are ready to start getting your  ducks in a row to launch a project, it is very simple:  Know how much you can spend, how much time you have to get it off the ground, how good it needs to look and what you expect back for it.

I hate using the phrase “managing client expectation” – but a project can easily result in an angry lawsuit, dissolution of friendships or partnerships, even bankruptcy if everyone expects different returns out of a project.  Early and constant communication is key, clearly defining roles and a written scope of what will and what will not be included in the delivery of a product – all of it is essential.  Often times I have found communication problems usually come from a Business Leader or ‘stake holder’ who may have seen a flashy demo from a Supplier and heard that product referred to with a certain “catch phrase” -  said Business Leader makes an assumption that this catch phrase is an industry standard term – they believe something to be a standard because they were told by someone who was trying to sell them something that it was or is “best in class”.

A recent example I have run into is Telepresence – depending on if you are Cisco or Tandberg, the definition of what is meant by a Telepresence-type experience is similar, but the tangible products work differently and do not play well together….

Business Leaders live outside the inventor and developer space where we create and use new technologies daily and understand  the nuances that result in a lack of standards – we know that there is no such thing as a standard application on web or anywhere for that matter;  there are many variables to account for (amount of bandwidth, Operating system, web browser and security settings, firewall, location restrictions, on and on… ) No one has been able to offer a completely “ubiquitous” solution for anything…

So – for starters, it is this “class of service” we first devise when creating a project strategy – doing this correctly is so critical, and is a an art form in and of itself – one has to do this incredibly well in order not to get a reputation in this industry for being a hack or a thief – and what I mean by that is, if the end product has to meet a higher level of expectation, more time and money must go into the planning of the project – take for example Enterprise class, which by default would include 99.999% up-time SLA on any web based product, the product will need to be well branded and it will need to  stand up to a higher level of expectation on stability then perhaps something that is more of a functional product that just needs to work well enough to serve a less visible purpose… if you will?

In the next installment, we will look at the various tasks and streams of effort that are usually victimized by budget hacking, but will always lead to long term issues when neglected…