What Goes Into a Technical Proposal
Project proposals of this kind are quite different from in-company project business cases. These relate to projects where you are basically pitching another organisation to give you funding for your project. This happens in research, academia and sometimes other areas like business incubators for start ups. Let’s say you want to put a funding proposal together for a business incubator. You know you are eligible and you’re gathering the paperwork to prove it. You can put your budget together in the format they want. But the technical proposal…. It’s hard to know exactly what goes in that, even if you know your own solution perfectly and have already costed it. This is about communicating the value and approach of your project so it gets chosen over someone else’s. It helps if the funding-granting body has given you a template to complete. That certainly takes the guesswork out of it. If that doesn’t happen, you’ll be reliant on your own internal templates and they might not be geared up for this kind of application. Binda Zane has some pointers for what to include. The headings below are what he suggests goes into your technical proposal along with an explanation of how I would interpret those if it was my project. IntroductionPop something in here to set the scene. Personally I would write the introduction last so I could make it contextually relevant to the rest of the document. If you don’t normally leave it to the end to write the intro, try it next time – it’s so much easier! Current context and proposal structureThis should cover the context of the project and any background information that’s useful for the decision makers to have. It could also describe the research you’ve done (not in detail) or other sources from which you’ve drawn information to prepare this proposal. It’s also a kind of executive summary that outlines what they can expect to read in the proposal and gives them the headlines in an easy to digest format. MethodologyYou’d cover off the project goals and objectives. This would be just like a standard business case. Binda Zane suggests that you talk about the tools and techniques to be used. This can give the decision makers confidence that you do have some clue about how to manage a project. If you can say that you’re using industry standard best practices and following guidance from PMI (or whatever methodology/standard/processes are applicable to your business) then do. I’d make sure that governance gets a significant mention here. If you were asking for my money I’d want to know that you had controls in place to spend it sensibly. Of course, you shouldn’t say that you can follow standards if you actually can’t. That would be a breach of the PMI Code of Ethics and Professional Conduct. Other professional bodies have similar ethics standards. You’d also want to include a section that outlines your detailed approach, the work packages and the descriptions of each task, at least to a sensible level that tells them what you are all about. If you think this section might go on a bit, move some of the task descriptions or detail to the end and put it in an appendix. Organisation and StaffingThis section covers what they need to know about the people who will be involved with the project and how the work would be organised. Binda Zane suggests management of quality control is covered in this section but I think there’s some flexibility to move it elsewhere if that makes better sense to you. I think I’d include this in my methodology section but there could be good reason for keeping it here. Up until now you’ve only talked about what you will do, and how you will do it, but there hasn’t been any talk of how long that will take. Mention the timescales, major phasing and anything else relevant: key milestones, reporting dates and so on. You also want to talk about the project team in this section. Describe the make up of the team, the organisation structure for the project and the roles and responsibilities of the key players. AppendicesBinda Zane recommends two appendices. You can dump information in here that would take up too much space in the main proposal but is still useful for the audience to have. His suggestion is that you include the CVs/resumés of the project team and also a selection of project references. By that I would surmise that you could include references from past clients about similar projects, awards your team has won for their project work and anything else that makes you look like a solid and stable organisation. That should give you a solid project proposal – for the technical element, at least. What else would you include in a technical proposal? I’m interested to hear your thoughts about what might be missed out of the list here! |
How much documentation is enough?
The amount of documentation stakeholders need to feel comfortable depends on:
According to Tom Kendrick in his book, 101 Project Management Problems and How to Solve Them, there are three types of project management document: Definition documents: these define the project so include things like the project charter, requirements catalogues and organisation charts. Stakeholder management/engagement grids and analyses also fit in here. Definition documents might sound static, but they actually need updating regularly as things will always change. Planning documents: these help the project team plan the work. They include the plan (of course), risk register, the project schedule, and any other project-specific sub-plans like a communications plan. Status documents: these are the documents that stakeholders are generally most interested in. While they should be interested in the requirements and the risk log, you’ll find that the majority of stakeholders only really want to know how things are going and what they have to do next. Status documents include the things you would expect like regular reports, the issues log and follow up actions, the change log and other regular, non-standard documents that discuss status like meeting minutes. Where does your project budget fit in all of this? Well, it’s partly a definition document: as part of the project initiation activity you would have defined the budget in the project business case or initiation document. But it’s also a status document: the real-time changes in the budget and tracking how much you are spending is very much related to project status.
Those two documents are ‘enough’ for my project budget. I can pull extracts or summary figures for my status reports, and that satisfies my stakeholders. How do you manage your project documentation, and do you find yourself doing just enough, or producing documents that no one ever looks at again? |
Finance Filing: get your records in shape
If your project team members work for you, you’ll probably already have visibility of their salaries, expenses and bonus arrangements. Don’t lump all this in with your ‘project’ records. If the project team works for someone else who has asked for your input to their performance review to award a bonus, or you are responsible for their expenses or timesheets, don’t store this with the project records either. Create a separate, private, ‘Personnel’ filing system for this type of sensitive record. |