Systems engineering and proposals for the transportation industry
Our services focus on the discipline of systems engineering, in particular on requirements and interface management, on concept design and on proposal services including strategy, management, technical writing and editing.
We believe that a critical time for systems thinking is during the proposal phase.
We all know that proposals are under cost pressure as an overhead activity. Proposals are under time pressure as customers seek to recover procurement time schedules. This is a time when you cannot afford a large team - even if you could establish and manage it within the available time.
What you need are multi-skilled, literate, systems thinkers, who understand the domain and your business because the requirements to be managed are not purely technical. Meeting project timescales, corporate risk management, financial and commercial issues must all be resolved and presented in the proposal.
They must find the best solution that you can provide and then challenge you to address the customer's needs and concerns and not rely on corporate boilerplate and rhetoric.
SERVICES for PROPOSALS
Do you know whether you are really "bidding to win"? Or are you just bidding for the "exposure"?
Bidding and proposals are demanding on your staff. A rigorous bid is costly against the bottom line, but a poor bid will damage your reputation if you lose and be much, much worse if you win!
test the claims of your sales team about your competitive position.
map the fit of your product and solution against the customer's explicit requirements - and the unstated ones!
enunciate the position and your bid strategy to ensure that management hold a reasonable expectation of the outcome and are committed to support the bid.
ensure that the resourcing and cost of bidding is aligned with the win probability, value and risk of the opportunity.
"The greatest enemy of communication ... is the illusion of it."
William H. Whyte (1)
Proposals have particular demands, not least being timeframes and access to resources.
The proposal team is expected to secure commitment of technical and commercial specialists, who may have other demands on their time.
It is increasingly common that these contributors are spread across multiple locations, timezones and cultures.
Just when dealing with a task that demands absolute clarity of communication, you take a team that has not worked together before and expect them to communicate successfully and quickly ... and to do so through conference calls and email!
Our team has expertly managed exactly this situation multiple times. We have practiced techniques to mitigate the challenges of this approach.
Importantly our team is built on staff who have experience in all aspects of the business at heart so that engineering solutions are not developed in isolation of project management and commercial considerations.
Complex systems and projects are seldom delivered entirely by one company. Whether it is through subcontracting of elements of work or supply, or through the formation of joint ventures and consortia, it becomes crucial to quickly identify the scope share and the interfaces between the parties.
No gaps; no overlaps.
The best party to manage the risk should 'own' it
Contingencies are better held at the 'highest' level in the team structure.
Technical Writing and Editing
Our team has particular exposure to the demands of proposals and sales documentation, but is also experienced in developing training materials and manuals.
In proposals you need writers who can concisely and unambiguously express your proposition to your customers. But they must challenge your corporate temptation to tell the same story about how good you are instead they must directly address the customers needs and questions. They must sift through the details and features that your technical team provide and present the issues that matter to the customer.
Our team has the solid technical background to frame the documents and to work with your technical experts to fill the details.
On commercial matters we believe that the responsibilities should be apportioned:
the legal team to identify risks and legal mitigations;
technical and operational teams to identify practical mitigations;
operational and executive management to determine whether to take the (residual) risk;
proposal staff to draft and deliver the responses in line with all of the above and with clear approval of the position taken.
Our teams have the commercial experience with common forms of contract and with project methodology to draft responses and expedite this process.
SERVICES for PROJECTS
The delivery of electronic and software systems seems to remain one of the only areas of human endeavour in which it continues to be possible to start the undertaking without a clear idea of what it means to finish it!
Requirements are about defining - at the start - how you will know that you have finished.
Unambiguous: a good requirement is open to only one interpretation. Simplicity is desirable, but don't be afraid to use that extra clause if it is necessary for clarity.
Language: in a multicultural world beware that the nuances of language may be lost on foreign speakers (and on many native speakers, too!). There are plenty of examples of phrases that can mean exactly the opposite between US and UK forms of English.
Testability: if a requirement cannot be tested, how can the contractor know that he has satisfied the requirement and how can the customer argue that he has not?? A requirement for a system to be "user-friendly" is at best 'aspiration'.
Traceability: every system requirement must have a source in the customer's requirement. There are few surer ways to overprice a bid or overspend on a contract than to build for requirements that were not specified. Conversely you cannot permit user requirements to 'disappear' as you work down through the analysis of the system.
“I know you think you understand what you thought I said , but I'm not sure you realize that what you heard isn't what I meant”
― Alan Greenspan
'“In this age of specialization men who thoroughly know one field are often incompetent to discuss another."
― Richard Feynman 2 May 1956
Caltech YMCA lunch forum
(1) The attribution of a similar quotation to George Bernard Shaw appears to have no basis.
Interfaces are just a special case of requirements. But what makes them special?
The difference is that, for interfaces the "devil" really is in the detail. Missing a detail on a functional requirement generally has a small impact on the system acceptability. Missing a detail on the interface can mean that a critical system interface fails to function AT ALL.
Moreover, the existence of an interface is often a one-line requirement. For a number of reasons the process of defining the interface can continue for some time during the project.
For example, if the interfacing system is new, the detail of the interface may not even have been defined yet. Conversely, when interfacing to a legacy system, the details of the interface may never have been properly documented and the legacy system may be very fragile in its handling of out-of-design conditions. Either scenario requires ongoing management of the interface in conjunction with the 'owner' of the interfacing system.
Define and agree the process and responsibilities for interface definition and control.
Define the interface control documentation
Agree the interface definition schedule
Prepare and check interface control documentation.
Secure signoff by both interfacing parties and other stakeholders
Manage the process of changes to interfaces and interface documentation.