Big enterprises are infamous for creating lots of processes. Sometimes these processes are overburdening for the team members that have to do them to the point where the process is more work than the actual job to be done.
Sometimes, these processes are needed to make sure Project Managers and Executives are able to obtain the business intelligence.
What is the gauging factor to decide if the process at hand is good, or too much?
There are two components to the question: 1.) the view of the project team members and 2.) the view of managers.
One thing to make clear to the team is that the information that management wants comes from a lot of these processes and that information can also be the same information that rest of the project team needs to do their job. By showing to the team members that following the process helps the team, too, their willingness to follow the process increases.
In my experience, technical team members in IT and Architecture (building design) rarely complain about spending 2.5% to 5% of time on generic overhead tracking tasks, which equals 1 hour to 2 hours per 40-hour week. If there is an extremely complicated project (global, multi-vendor, multi-phase, etc.) up to 10% seems to be tolerated for short periods of time. If you survey your team and the average time spent on process tasks (revising estimates, writing change requests, status meetings, etc.) exceeds 3 hours per week per project member (not counting the PM), your process might need adjusting.
What is the gauging factor to decide if the process at hand is good, or too much???
One common trend I've seen in large enterprises - a gauging factor, if you will - is redundancy. If you, as a PM or an Executive, have the ability to modify processes, then you will definitely need to invest time and energy to ensure there is no duplication of effort.
For example, in some organizations, there are multiple documents that need to be filled out for software/ IT Release updates. Although there are 3-4 different documents that the team members/ PM need to fill out (implementation plan, impacted systems, roll back, contingency plans, etc), there is usually a high degree of redundancy across these documents.
The excuse usually given is that these documents are circulated to different teams (Finance, Internal Audit, Release Management, PMO, etc) who need to feed various pieces of info into their systems.
If you can sort through the various templates ahead of time and streamline / amalgamate the processes and documentation, then it will certainly reduce the burden on your team. Of course, there would be a slight learning curve for the various departments downstream, but if you can get everyone at the table ahead of time, it can usually work wonders.
Alas, we cant eliminate the bureaucratic processes entirely. -/
I have worked as developer with a very overburden process and the team didn't see the benefits of the work.
Of course this process directly affected our job to be done.
We improved the process to a more dynamic process where we could see the benefits and also concentrated most of the work at one person, so the rest of the team were free to do the job itself.
If the process is really important to the organization. So you should think whether it is better to dedicate someone to insure the proper functioning of the process (as a coordinator of the process) and allow the team to communicate relevant information to this coordinator. The team will be more free to do the job.
Another point is to review the process in order to set what process work will bring back benefits to the project/company.
Does it help you do your job better?
Does it help the team members do their job better?
Many times the answer to this question involves using the right tools for the job. Strategic decisions made by management can only be made if they have access to aggregate data about the project.
Part of the job of a developer is to provide this information to project managers and executive level management via project management software and other forms of documentation.
If a development team spends 100% of their time coding, they may get a lot done, but consider that what they build may be 180 degrees in the wrong direction from where it would be with the proper information.
Even the fastest ships can't get to their destination without a good navigator.
The collective answers on this are all quite valuable. However, one thing I haven't seen mentioned is the value in automating processes where possible. For example, much of the pain in software traceability has been mitigated through better tooling that allows (for example) easy linking of source code checkins to items in the work tracking systems that they are implementing, which in turn can be easily linked to both higher-level work items and the supporting design artifacts that can easily stored and maintained in (again, for example) a team wiki.
When the data collection for processes is automated, it becomes quite easy to build and generate appropriate reports. This does, however, cause some degree of tool lock-in as a hidden cost of decreasing the transactional costs associated with following processes.
I see two questions here.
Most of the answers attacks (very well, some +1's around here!) the secondary question, but I'll try to focus on the first, in subject, question:
What to do when team members are overburdened by process?
Let's assume we're chit chatting about this question in the IT lounge of a big, Forbes 500, Financial company.
It's common sense that IT folks simply HATE bureaucracy. IT people tend to anarchism, in a good sense. So, throwing a pile of paperwork on them will for sure create the chit chatting on the previous paragraph.
So, back to the original question... what to do about it?
In this sense, SBWorks in his answer raises a very important point: documentation is not senior management only. Especially in big companies like this we are, in the 18 floor, this gray carpet and windows from top to bottom of the wall, documentation is vital. Is mandatory. Is regulatory. Bottomline:
It's not a matter of doing 'enough' documentation. Is a matter of doing all mandatory documentation.
And doing so as better as possible. You for sure don't want those big guys from Wallstreet hating you.
And here I believe the best answer is Mark's, with:
Enough is what helps the team.
Sounds simple, right? It's not. Definitely. IT keeps complaining. IT complains of everything.
So, to have IT stopping complaining about the documentation, explain them the underlying reasons for the usability of so much documentation. Before try to explain to them, make sure you accept the answer for yourself. If you find no reason, go talk to the people responsible for the process and discuss with them.
The idea, in de end, is to get rid of the documentation no one explained hot to use and keep very attached to the documentation in place. Doing so, there will never be 'documentation overload'.
