Common Project Issues: R & D - Too Much "D" and Not Enough "R" - Part 1

As Project Managers, we are often working with some of the most talented and creative minds in our organizations.  On IT projects, we’re equipped with cutting edge developers, experienced business analysts who know the software inside and out, and architects and data specialists who can put the finishing touches on a very successful system.  What happens when they put too much effort into performing the work without fully understanding what work needs to be performed?  

This can happen two ways:

- Over-anxious team members starting work before they should

- Lack of detailed requirements gathering before starting development work

The Standard Process

We’re all familiar with the standard project flow.  Requirements definition, followed by design, development, testing, training, implementation, support, and move on to the next project or phase.  When the Project Manager has the right team, the detailed schedule and the other PM tools in place and being utilized, then this flow of activities can be fairly smooth.  And if it’s not, the tools are already in place to identify and communicate the issues as they arise and the teams will work toward mitigating those issues.

However, there are those cases when an over-anxious developer may start the “D” (development) before the “R” (research...or in this case, requirements) is fully documented.  While this may not cause major project issues, it can be detrimental in a number of ways:

- Frustrate the customer if they see that leadership is not in control

- Expensive to the delivery organization if re-work is needed due to unfinished requirements

- Impact to the project timeline to re-work and re-test development work that is performed prematurely

Expense and timeline impacts are bad enough.  If they are minimal, they can be eaten and possibly made up in a later phase.  The one that is hard to undo is customer frustration and dissatisfaction.  It’s like making a good first impression on someone.  That first impression is very hard to overcome.  Overcoming a customer frustration can be difficult and any subsequent issues can result in the customer requesting that the PM – that’s US!! – be replaced.  Not a place we want to go…

Keeping Tighter Reigns 

Thankfully, we have the tools in place.  The good PM is managing the project well with the Project Schedule, the weekly Project Status Report, and weekly formal Project Status Meetings happening regularly as well as at least one organized delivery team status discussion. 

As the Project Manager, if you are engaging all team members in regular weekly status discussions as well as daily adhoc project communications, then it is far less likely that a rogue team member is going to act on their own and begin tasks out of order.  They will understand the tasks that should be in progress and the tasks that are upcoming because they have the Project Schedule and it is driving the project and they know that it is accurate, up-to-date and that the PM is in charge.

But What If?

That all sounds good, but what if this still happens?  It happened to me on a small internal web project for a very large international engineering and aviation company.  I was still finalizing requirements with the project sponsor who headed up the business unit that had requested the web project.  The developer, who left a requirements meeting ‘knowing exactly what the sponsor wanted’ began developing the solution while I was still documenting the requirements. 

I discussed the issue with him and also with the development manager to ensure that this didn’t happen again…and it didn’t.  Catching it very early meant that the budget and timeline impact was very minimal and definitely recoverable.

Summary

As the Project Lead, the Project Manager must maintain tight control of the project resources utilizing all formal tools possible.  The better informed the project team members are, the less likely they are to begin tasks out of order.  If they understand that the project is organized and being lead competently, then they will be less likely to feel the need to take initiatives without the proper authority to do so.