Project proposals in smaller organisations: That moment when…

‘… can you just write us a little proposal about this …? – The moment your project really starts!

You might know this moment: You’re working in a small organisation (one without rigid structures or well-defined processes in project management) and you have come up with a good idea. You started developing it slightly, you’ve chatted with some others about it, and finally you have presented it as an idea to your seniors.

And guess what, because your idea is really good and you have presented your idea well, you now casually get tasked with developing it: ‘… just write me a little project proposal’… and then you realise your project has the potential to become reality!

For many of us this is the moment of great excitement but also of some level of heart-sinking. How on earth can I communicate this idea and all its add-ons clearly? How do I write about it knowing the very different requirements and goals within the wider team?

Remember that a proposal doesn’t have to outline all the fine details! In small organisations especially, people would just be interested in the big picture, the problem you have identified, the solution you propose and the resources required to get this going.

My suggestion is: just take some time to think! (I often take a couple of days to mull things over in my head – give yourself time)

I find it very helpful to do a brain dump/mind map on a big piece of paper:

Once that is done, you can apply some simple structure to your project proposal:

1. Introduction

Say in just a few sentences what the project is about, which issue(s) it addresses, what your solution is and what the final change could achieve.

This is just a short taster to whet people’s appetite… So keep it short and sharp!

An example: ‘Project ‘HR portal’ will allow all staff at all times to access current HR guidelines and forms. Due to the working pattern of the HR team and the not-very-organised HR section on the intranet site, this is currently very difficult.’

2. Motivation

With this second point, motivation, we have an opportunity to explain the background of our idea. You could outline briefly what the history of the problem is or why a problem occurs at all. Maybe there is a workaround but it’s not very good.

For example: ‘At the moment, guidelines and forms are photocopied and passed on from person-to-person. However, staff members can never be sure, whether they have the correct documents and guidelines. Additionally, this workaround means that HR are generally out of the picture.’

3. Project summary

Give a very high level but precise description of what your project will achieve.

This could be something like:
‘The restructuring of the HR section of our staff-website into a curated information portal will allow easy access to up-to-date HR policies and forms all the time.’

4. Project details (the nitty-gritty)

This is the point where you can outline all the finer details of your project. Make sure you structure this clearly so a reader who has no previous knowledge of your project, can clearly understand what you are trying to achieve.

It’s usually a good idea to use some larger sub categories!

Going with my example that could be subjects such as:

Project environment: creating a new section on the web site which will function as a portal.

Teams affected:

The HR team will need to be on board and provide all up-to-date documents! They will also need to take ownership of this portal when it gets handed over to them.

The in-house IT team will need to commit to set up the necessary structures.

Your project team will need to collate which guidelines and forms are required, collate them, populate the new portal in a user friendly and intuitive way. Maintenance documents will have to be provided so that the HR team can indeed take ownership of the area later on. Training might need to be arranged.

Issues:

Patching-in a new section to your Internet may be a challenge if there is nobody with that expertise on site. Clear communication will have to be provided to developers and indeed, of course, internal IT teams, too!

Very often, you will find that you will have to navigate between different people’s ideas at this point. It helps to bear in mind who your stakeholders are, whom your project is supposed to serve and the constellation of your team. However, stick to your clear idea!

Deliverables:

This bit is totally key to your project. Especially in a smaller organisation, it is really important that you set boundaries around what you are going to deliver, and that you know when you have delivered the final product. If you don’t agree at what point you have finished, projects can easily run on forever. Make sure everybody understands where your commitment ends. For example:

• development of fully functioning and populated HR portal
• Portal handed over to HR team

You must clarify that you are responsible for developing and populating the portal, and that once you have handed the fully functioning product over, you are done.

Timeline:

This is a tricky one in smaller organisations as you rely on so many variables and you will most likely not be formally assigned the needed resources. All you will get is a vague commitment maybe. Be cautious to not state un-realistic timelines, but rather suggest a broader spectrum of time. Outline at this point, that this depends greatly on the above-mentioned teams cooperation.

Conclusion:

Write a short summary of the project including, again, (briefly) the problem, your motivation, the proposed solution and also showing the benefit of your project.