Don’t Agonize… Organize!
Whenever I start a new project, one of the first things that I put some thought into is the Project Organization. Why? Well, what I’ve learned over the years is that a) each project is unique, b) there is no “cookie-cutter” approach to the successful Project Organization and c) I am pretty sure that poor project organization is one of the main reasons of project’s failure.
What makes each project unique is largely determined by the environment, people and the scope of the project. Because of those factors, what worked on your last project, will not work on your next.
If project is small in scope and is involving you (doing the work) and the client (approving the work), there is no real challenge with the project organization. Things become more interesting, when everything is scaled and multiplied a few times over.
There are two main groups to any project ‚ the Doers (Developers, Designers etc.) and the Influencers (Stakeholders, Decision-Makers). What should bring all those people together is the Common Goal of the project. It’s important to keep Stakeholder groups small (decisions can be reached quickly), but include representatives from the various groups, so the organizational needs are not overshadowed by the needs of the individual departments. Sometimes you need to create Working Groups of Stakeholders to ensure project governance and good co-ordination. Just don’t mix two groups together. Development team needs to be focused on the tasks at hand and doesn’t need to hear more than they need to complete those tasks. You’d probably also want to use a different language when communicating to those two groups. However, it’s a good idea to have a person in between, that can update both groups with the important information throughout the project.
- Process & Governance
Most organizations have some kind of process in place. However, very often no one follows it. This happens a lot when the things you want people to do is outside their main responsibilities. The fact that its best practices to share information and don’t duplicate efforts etc., has very little effect on them, as in their mind, it’s not their project and you need them more than they need you.Another reason processes are not followed in the organization is that sometimes individual units believe they have full control and decision-making power over the projects they are involved in. Even when projects require everyone working together, individual groups still do things their way, without considering the impact they have on mutual projects. This highlights a problem with project governance. So address the Project Governance before you start the project and you‚ you’ll be better off than those who didn’t.
A lot of times this aspect of the project is overlooked in the beginning, but sooner or later, you‚Äôll have to figure out which tools you all should use for daily communication and collaboration (email, messengers, wikis, bug tracking software) and for file sharing (shared drive etc.).Here are a few tools that I prefer to use on smaller size projects:
- Skype – for communication with those, who are located in different countries, because it’s free between Skype to Skype users.
- Google Docs – for sharing documentation and sometimes even as a bug tracking tool, because of it’s simplicity, most users familiarity with the spreadsheets and word-processing tools and because you can access it from any place that has a connection.
- Edistorm – for brainstorming and personal task management, because of it’s simplicity and interactivity.
- Bugzilla – for Bug Tracking, because it’s free and widely known in the development world.
There is a good comparison chart on various Bug Tracking software on Wikipedia.
- Unfuddle – as a hosted project management solution for software development teams that work remotely.
I’d like to hear what tools others use. Feel free to suggest other sites and tools in comments below.
This one is a hard one to tackle. I think this is one of those topics that have been debated forever.
There are no hard and fast rules on how much documentation is enough. Documentation is usually done, as needed, and a lot of times project is not described properly until the end, or sometimes ever. Often when you join a team, you have to do some reverse-engineering and find out what the initial requirements were by going through tickets of tasks and bug fixes.I think amount of documentation you need to produce for each project is dependent on the team’s maturity level – the more experienced people you have in your team, the less detailed documentation you can get away with. However, you always need to have high-level project description, capturing key requirements and milestones.
A number of aviation disasters have been largely attributed to problems in communication. And I am sure every single industry and every single project has some kind of communication problems. That’s because there is no such thing as a perfect communication, especially when large number of people are involved. No matter how well you try to communicate, you can’t control how your message is received. There could be language barriers, the wrong interpretation of the data presented, or simply the luck of understanding of technical terms.I’ve heard this phrase a few times now “If it’s an important message, it needs to be repeated 3 times. It’s so true. Communication within many organizations is like a broken phone game – by the time the message reaches you, it’s already been interpreted and distorted multiple times.To minimize some of those communication problems:- Make sure you communicate often, repeating important messages, at least, 3 times
– Communicate through various channels (don’t stick just to email)
– Don’t forget to talk to people face to face (this is still the most effective way of communication)
– Use images to help others visualize what you are trying to communicate
And last, but not the least, organize your desk!
It’s easy to clutter your environment, when you work on multiple projects at the same time. I personally can’t function when there is a mess around me. So before I add another project to my plate, I start by cleaning out my office and organizing my desk. It gives me a fresh start.
Though, your desk probably shouldn’t be completely empty. Lol
“If a cluttered desk is a sign of a cluttered mind. Of what, then, is an empty desk a sign?”