Posts Tagged ‘Budgeting’

If “double dip recession” happens, is your IT group prepared?

Tuesday, August 9th, 2011

I started writing this blog a couple weeks ago…so, now that the market has dropped by 10% it might not look as impressive that I am asking this question.  Obviously, we’re all hopeful that the economy can stabilize and all of our budgets don’t get cut for 2012.  Unfortunately, that might not be the case.

“More with Less”

If you look at Celent’s CIO study from earlier this year, the major theme was: Business expects more from IT. They reference supporting expanding list of initiatives, prioritizing across business groups, escalation of expectations of IT, and balancing cost reduction/capability creation as key challenges and pressures they’re facing.


In the last downturn, companies settled for budget cuts equating to less productivity.  Now, I believe we’ll be challenged to get the same amount done for less budget. So, what can be done?

  • Go Agile – if you’re already using an “Agile-like” development methodology, great.  Dive in and examine how you manage your priorities, who the impact players are, and which areas of the process are adding most value.  Eliminate everything else.
  • Get the most out of the tools that are currently available – FAST 8x  ( is an example and I’d be remiss if I didn’t promote our own software.  With FAST 8x, you can build smaller components to solve targeted business problems at a fraction of the cost, time and risk.
  • Avoid big mistakes – Diversify by spreading out your initiatives and deliver value sooner rather than later.  Don’t buy that big packaged core system that is going to be a burden on the entire organization, cost too much money, and risk the farm.
  • Staff reduction is not a “cure all”.  Obviously, eliminating staff and consultants are necessary triggers that can be used to work within a budget cut, but that will most likely compound the problems with the business needing more.  In some cases, you might want to cut even deeper to free up cash for tools and the “right people” to help you navigate through these times.

Pressures and challenges could increase.  Are you prepared?


Tom Famularo


Fixed Price Waterfall Projects: Perception vs. Reality

Sunday, July 25th, 2010

Many years ago, my old company (which was a small software and services company that did large projects) got tired of the unpredictability of cowboy programming and we embraced a waterfall systems development methodology with the fervor of the newly converted.

We would capture detailed business requirements that would let us determine the “whole cost” of the project and create a bullet-proof implementation plan.  We could even commit to a fixed price for the known scope – really it was a fixed price for implementing our interpretation of the business requirements. When we wrote the functional specs, we would learn even more and get some additional requirements, which would result in change control items.  Thanks to our waterfall methodology and rigorous project management, we could explain why the project was getting bigger.  As we started to code and learn even more about the requirements – the scope and cost would grow some more and the date would start to shift.

Months later, we would complete our testing and deliver to the client – and the business users would say “this isn’t what we want”.  And we would say “but it meets the spec”.   This would lead to weeks of contentious conversations and analysis and justification.  Ultimately, we’d all agree to a compromise no one was happy with.

This was done in good faith and with good work efforts all around.  However, the reality was that the fixed price would be for a defined amount of scope (call it “X”), but the project would grow legitimately because of new scope or new interpretation of the documented scope.  Before you knew it, X became 2X, which made for some painful projects and some contentious client relationships.

When I started working for a larger, more established company, I learned that there might be a better way.   I learned it was better to estimate all of the likely costs up front.   So, we spent more time on requirements and got even better estimates, more bullet-proof project plans and detailed scope definition.  Unfortunately, the costs still went up during design and build – but at least we had much more data to explain why the project was a lot bigger!

Especially in the world of big insurance systems, I believe there is a large gap between perception and reality when it comes to fixed price waterfall projects.  At the risk of stating the obvious, I have listed below some of the areas where I see the gaps.  There may be good business reasons or constraints that steer you toward the fixed price waterfall approach, I would just recommend that you go into it with your eyes wide open.



A waterfall project with a fixed price contract lets me know what my cost is going to be Fixed price contracts let you know what the cost is going to be for the vendor’s interpretation of documented scope. Typically, large multi-year projects will cost multiples of the initial estimates due to change control items.
Defining the scope up front is worthwhile because I can make sure that everything I need will be in the system. You spend way too much time defining scope and creating “bound scope” and not nearly enough time prioritizing scope.  Too much unnecessary scope is documented and many important requirements are missed and become change control items later.
You can document enough to bind the scope Until the client sees the functioning system, there is no way to remove “interpretation risk”.  There is just not enough time or budget, typically, to review and discuss every requirement and spec to ensure there is no misunderstanding.
A tight change control process will ensure that management will understand and buy into scope increases Management will not have the bandwidth to focus on change control items.  It won’t be one big item, but a series of smaller, detailed items that drive the cost up.  Ultimately, the scope will grow significantly and management will not feel good about the rationale.
Fixed price contracts favor the client Fixed price contracts favor the vendor if the vendor is sophisticated enough to manage change control process properly.
Fixed price contracts make for a smoother relationship because everything is documented A good vendor project manager will know the contract “inside and out” and will be ensuring that both parties uphold their part of the bargain.  There will be a lot of contentious discussions about what is in and what is out of the fixed scope.   Terms like “nickel and dimed” will be used regularly.

John Gorman