The problems of going fixed-price to set-up an intelligent building, Vs Agile (time-charge) fee engagement.
When you’re trying to optimize a design commissioned system, you’re not getting a pre-existing commodity. You’re developing a customized system that helps you achieve your specific business goals. It should leverage (or provide the foundation for) organizational change. In other words, you’re not buying a product: you’re buying into a process.
I’ll even argue that if all do is buy “an implementation,” then you’re missing half the point of original design intent. If all you get is “automation,” then you’ll just be doing the same old thing at lower cost, instead of growing the top line.
Lets explore this in more detail….
When the client Says, ‘Forget Time-charge; It’s Fixed Price!’
For many, the biggest issue with intelligent design projects is the client not knowing what you’re going to get for their money. If the client doesnt trust the project team and the vendor (System Integrator Contractor) SIC; time-charge arrangements can indeed look like a license to steal.
The best answer to your clients concerns: Don’t even think about starting a project until you find a project team and a SIC that you trust. But that’s probably just crazy talk. In my experience, fixed-price intelligent building design projects are more likely to be complete in name only, with unhappy users, than they are to be satisfactory to users, with unhappy budget-holders. With the client spending more time and money later to get the system working correctly wondering why the this could not of been done by the professional project team employed originally!
For traditional building services projects, clients tend to demand fixed-price projects without actually preparing for them. In response, vendors often use three strategies for “fixed pricing”providing only a cut & paste implementations, selling just a bucket of hours (that is, not signing up to completing the deliverables), or starting engineering change order (ECO) negotiations almost from the outset.
To prevent this from happening, there are a few things to look for in the consultant/system integrator designer, as well as a few behaviours you need to follow along the way. Here’s a quick run-down of how things ought to work.
Step 1: Before Any Project, Do Your Homework
The RFI, RFP and RFQ drill works well if your team really knows the details of the business and technical requirements. Unfortunately, spec-writing teams tend to make three classic errors:
They simultaneously under-specify (with too many silent assumptions and incomplete information) and over-specify (with too many product-specific stipulations).
They’re vague (or even silent) about acceptance criteria for features. A spec without a test or a clear go/no-go threshold is a wish-list, not a spec.
They oscillate between the technical features, the business rules, and the overall goals.
Everything needs to be translated into pure system attributes and features. It’s pretty rare for a traditional building services consultant internal staff to really succeed with writing the specs on their own. Instead, bring in a specialist consultant who will be excluded from the bidding to help you set-up the design performance requirements and write an iron-clad spec of what you’ll needand only what you really need.
Step 2: When Short-Listing
As vendors (System Integrator Contractors) SIC respond to your RFI, RFP or RFQ, look for more than just good answers. Does the SIC include rules of engagement for the project? If there’s no guidance and dialogue during the bidding process about the how the project will be managed, then friction is likely to develop later on. There are just too many places for mismatched assumptions.
At some point, you’ll eliminate some SIC / vendors.
During your short-listing cycle, modify your specs and contract to avoid the problems that the out-of-the-running vendor has spotted. Even if you pay the vendor £180 an hour for this task, you’ll still save a bundle overall.
Step 3: Pay Attention During the Design Implementation
If the winning SIC is smart, they will precisely specify what it will (and won’t) deliver in the Statement of Work (SOW). Any change to the SOW will probably require an ECOeach with its own price tag. This will be true even if the following happens:
You didn’t understand the consequences of the specified deliverable. For example, the SOW might say “180 devices within 25 zones,” but you may have no idea whether that functionality will be satisfactory to your users.
You discover bad assumptions, additional requirements, or plot complicationsor you simply change your mindat any time after the contract is signed.
All the itemized deliverables do not solve your system problem, make your users happy or achieve your business objective.
Also note that the SOW may contain a line item for an explicit number of hours of project meetings, as well as another item for project management. If meetings or your decisions/approvals take longer than the allotted time, the vendor is within its right to issue a change order.
During serious fixed-price projects, meetings and the sequence of tasks will not be under your control. At times, it may feel like you’re working for the SIC: You’ll receive action items, decision deadlines and resource requests. In particular, you’ll need to complete your testing before features can be fully deployed. The SIC has to be running the show if it’s going to deliver on time and on budget with quality.
In other words, be prepared for the SIC to say “No” fairly often. If this all sounds a bit adversarial, it is. The SIC’s fixed price commitment is to delivering only the items you put in the spec, not to making you happy!
This won’t happen, though, if you prepare your team to the real requirements of fixed-price engagements. It may not be easy, but the short-term pain will result in long-term gains that make the project team and the client happy.