Now I understand this is difficult for any one individual to cover. No one could keep us all updated about everything. So I would propose something that requires the minimum input from each person and spreads the load among many people. So I would propose each person write a little update of the key highlights of their week in a public (to the project team) forum that all can review when they need to. The highlights should be just a paragraph or a few bullet points. Nothing more. Including links to other relevant documents If necessary.
Many people already do this in some way so it’s often more of an exercise in making this available to those who need it and finding a way to keep the sensitive info hidden while keeping enough info to make things meaningful. It’s something I’ve had to do for several years so I know it can be done.
What I would then ask each person to do is build up a document of organisation. You don’t have to call it that. All I mean is a summary of what they are planning to do over time. What standards they work to and expect from others. Key deliverables they’re expecting or are being held to. Again I’d keep it simple and to the point. So people can dip in and dip out.
How this info helps me is in understanding what is and is not required to deliver the project and also how I can justify the time I am spending. For example on one project. I went to extremes to involve the wider community and also bring in partners so it didn’t seem like an initiative completely led by the company I was working for. I did work afterward monitoring what was happening elsewhere and building relationships. Yet in projects it’s not always clear to me whether I can put that down as chargeable time. I have worked places where that’s frowned on. Where if you’re not sitting at your desk programming then it’s considered wasted time.
What I’m trying to say is that I like to consider each person in the project. They will have different ideas and experience of working in different ways. They need support to feel they can discuss some or all of those ways with the project members and ensure that processes adapt to give them what they need. This support is needed in many different areas.
- Some political (People supporting what others are trying to do and encouraging them),
- Some technical (Project members need to know the reasons why things are done in the way that they are, the risks in change, what is a good place to try new ideas out, first as prototypes, then for real),
- Some conceptual(For example a lot of the challenge in Offline Moodle project I've been involved in is that the course is not fundamentally designed for offline/mobile access. This is presenting a cost at the technical end yet the issue isn’t entirely technical. It would help to be working directly with students, al’s and course teams to understand the issues at the delivery end. This is why I've had talks with this in mind.)
For me a key issue is what you need from each area i.e
General
- Simple approaches to communication within each team to ensure cover when members are unavailable. So everybody knows who’s responsible for what, who to go to and also what each person needs to know and also doesn’t need to know. Where does their responsibility end.
- What can each team do to help the other?.e.g. the customer facing team providing an FAQ list to the delivery team who then return it filled out with fixes and answers.
- What are the boundaries between teams. On a technical front. How much testing should developers do before tech testing get involved. Should we all be sharing testing tools. Should we share our developing tools with testers to speed up testing. What is the service level agreement of each team or area. When does their responsibility begin and end. Who should they be working with and not working with.
- Integration of our developments with wider developments
- A reliable foundation on which to build what impact is one area having on another. What is being done to resolve this One of the key issues that this kind of approach helps me with is in defining what is defining the actual requirements. The itches you really want to scratch and thus relegating the others to those that can be dropped if necessary. You generally need to know your own limits before you can reliably negotiate these with your customers and acheive the right balance. This often requires a lot of discussion and you need the info on hand at any point.
- Defining your working practices and service agreements. Because all your key participants are being clear about how they work. Their expectations etc. You can come up with a good summary of these and define where both yours and your clients responsibilities lie. Thus you will both have a much clearer idea of what you're getting. You'll also be able to provide a summary of all the references used to provide this'project contract' or specification from the exact point at which it was issued. If things change you can agree new terms but you should both have a record of the terms agreed at that point.
My aim at the start of any project is to send to all project memebers a mail with a few links on it that lead them into the relevant sites and documents. This mail is something they can store and view when they want. Offline so to speak. They can then follow the links and discover the answers on a need to know basis. They receive updated emails over time as things change so they always know where the latest info is stored and get brief updates.
Again this is all what many people do already but it needs to be a coordinated part of the project teams culure. To ensure this info is embedded in the project culture I would have standardised specification documents. By that I really mean templates. Nothing fancy. Just a word document with most of the wording and sections already there. It includes a list of urls linking back to the places outlined above ensuring that the requirements of each area are considered.
By regularly seeing these links and following them, the requirements of each area then become ingrained into every project and into the mindset of those involved. Processes begin to work because every one becomes familiar with what they should be doing, and, as processes change there is a defined place to read about these changes. As opposed to this being agreed in a meeting you didn’t attend for some reason, or this being sent in a mail that’s got lost in the hundreds you have in your inbox.
I apologise if this is teaching you to suck eggs but it just doesn't happen regularly on many projects and people often question why they should even try. Yet without this I personally find it difficult writing road maps and specifications because there are often so many fingers in the pie yet no one is telling me clearly and succinctly
- what they want
- how they want things presented and reported
- how I can justify to everyone why I’m choosing a certain set of solutions i.e how to explain that what I believe I need to do will actually achieve what they need in a language they understand
The final thing to address is consistent regular feedback. It doesn't have to be every day or week. Some times every few months. But people need to be kept abreast of what's happening, the issues other people need to resolve, blockers etc and also what other people could do to speed things along. If the idea isn’t quite right then a response indicating why is also helpful. I always expect to begin with a first draft idea and then refine from feedback until I have something that fits all parties.
In essence this very article is the approach I am suggesting. It actually started as an email to others in the project explaining how I've worked successfully before. I've now just redrafted it to protect the innocent and make it more generic. Thus I have written it once and should now be able to reuse this later. Much like the rest of this blog.
No comments:
Post a Comment