Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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?

share|improve this question

7 Answers 7

up vote 8 down vote accepted

There are two components to the question: 1.) the view of the project team members and 2.) the view of managers.

  • Team members want the processes to quick and as painless as possible. They want to do their current task and move on to the next. Anything that you can do to make following the process faster (on line forms, single time sheet, easy edit WBS tracking, etc.) can make the team members more likely to complete the process
  • Management wants accurate, current information on what is going on. Occasionally, they want detailed information that unavailable and may hound the PM for it. If the team doesn't follow the process, the chances of inaccurate information contaminating decision making processes increases.

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.

share|improve this answer
    
Hi SBWorks, you mentioned a surveyed. Any examples or templates that you have found useful. –  Geo Feb 15 '11 at 13:49
    
I use the simple survey tools built into SharePoint. I use that for my projects already so it is easy to create a quick survey. I tend to asked for a rough percentage for work for 5 or 6 topics - how much time do you spend on X? on Y? –  SBWorks Feb 15 '11 at 14:21
    
+1 as team members, we try not to think about the why of process. Business intelligence is worth the pain sometimes. –  ashes999 Mar 27 '11 at 11:37
    
Do you happen to have any public research behind these percentages, or are they observational only? I'd love to see published or blogged material around the specific experiences if you have links available. –  Eric Willeke Apr 7 '11 at 6:02
    
No, I've never found any research, either. This is based only on my own observations –  SBWorks Apr 13 '11 at 0:16

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. -/

share|improve this answer
    
+1 to the concept of eliminating redundancy. –  Eric Willeke Apr 7 '11 at 6:03

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.

share|improve this answer

Does it help you do your job better?

Does it help the team members do their job better?

share|improve this answer
1  
I get your point, being PMs being the main person to reduce or increase the needed processes. Now, how about when the organization requires the process, regardless. If the TM or the PM do their job better, will they have to do less process? –  Geo Feb 15 '11 at 3:32
2  
This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. –  Lunivore Oct 7 '12 at 16:11
    
@Lunivore The OP is asking "What is the gauging factor to decide if the process at hand is good, or too much?" My response provides two questions to ask to help make that decision. It directly answers the question. –  Mark Phillips Oct 7 '12 at 20:47
1  
Hi Mark, apologies for the terse comment - that was autogenerated. Would you please consider a quick edit to your answer? I think it would benefit from an explanation of why it answers the OP's question, and perhaps some examples of processes which do and which don't help individuals / the team. That may also get it more upvotes. At the moment it does read like something that would be a better comment than an answer. –  Lunivore Oct 8 '12 at 9:09

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.

share|improve this answer

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.

share|improve this answer

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'.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.