Just a quick discussion to set the stage here. 

Different organizations are different!

For some companies, “projects” are one-off activities separate from their core processes, or basic business, such as making cars, or discovery of new pharmaceutical compounds, etc..  Here, it is critical to understand the dynamics in play when an individual is asked to contribute to a project while maintaining current duties within the core business.  The individuals insist they will do both, but the result is always: Core business process work first, and project work “when we can.”  In the end, process work always gets done, because this is the path to raises, promotions, etc.  With the best of intentions, equal attention is not equal, and the project work suffers.

Where Projects are King

For some companies, “projects” is all they do!  Examples include contractors, construction managers, and professional services consulting firms.  Why is this significant?  The management structure is different, and the culture is different.  These people just don’t see what the big deal is.  They don’t see the conflict between process and project.  More importantly, if you ask them to help you plan and execute your project, they won’t protect you from the conflict inside your organization.  It’s not their life experience.  They might see it, but don’t understand its root causes, or, how it can be eliminated.

What does this have to do with project initiation?  Everything!

Your teams will be cross-functional, because they will include members from multiple departments or disciplines, to adequately cover the project needs.  Try for dedicated teams, and eliminate the conflict.  If that’s not possible, there is an approach you can use, which I’ll cover in greater detail when we discuss execution.

Volumes have been written on this subject, so, let’s not reinvent the wheel here. 

There is a key point I would like you to consider, however:

How much detail is the right level of detail in a project plan? 

The current thinking is to limit the first level of breakdown to no more than 50, or perhaps 100 sub components of a project.  The assumption is any more than that and you’ll be overwhelmed during execution, trying to get accurate feedback on progress, and updating the schedule accordingly.  I think this is defendable where the update is manual.  Careful here:  You may be using software tools, but if your process requires a meeting or an email to get status, and then use keyboard entry to affect the update, the process is manual.  This is the single biggest drawback to how most software tools address this problem.  The assumption is a manual approval step is needed to allow the update, but later we will see this is not true.  More importantly, that 50-100 max is hurting you dearly, as we will examine later.

Vision with me, for a moment:

What would happen if we just let everybody self report? 

Chaos?  Not really.  If the next task requires completion of the previous, we will know in a very short time the next person cannot start if the previous work really isn’t complete.  If the next person is not in a position to know this (by skill, or perhaps, physical access), simply plan in a check step, to be performed by an independent auditor.  Incidentally, we audit everything, all the time, now.  How about if we only audit where we truly need independent verification?

Now, back to the 50-100 steps. If we self report, and we automate the roll-up and reporting process (more on that later) we can have any number of steps.  How many should we have?  Let’s make a few rules:  Each step will be assigned to only one individual.  No step will be worth more than 40 hours of activity, or take longer than 30 days duration.  Why these criteria? Because establishing percentage of completion takes your most experienced and expensive staff, and if we simplify this step to done, or, not done (0% or 100% complete) we can completely automate self reporting with computerized tools.  But wait you say, we need percent complete by step.  Yes you do, because you only have the typical 100 maximum breakdown steps. 

What if you have 1000 steps? 

Then each completion represents nominally 1/10 of 1 % of the project, if they are of equal scope. Use the actual budgeted hours by task against the total budgeted hours by project, and you have percentage of total project completion based upon exactly what tasks are done or to go.  Here is one of the first keys to Project Management Best Practices in the new paradigm.  Deeper, more comprehensive project plans, with no penalties, which lend themselves to execution across teams of virtually unlimited size.

As with project planning, much has been written on this subject, so, I will limit my discussion to Execution Management in the new Project Management Best Practices paradigm.

Remember that discussion about process versus projects we introduced under planning?  Here is where we will examine that in greater detail, and propose a methodology to eliminate this problem.

Suppose you are the department head of a manufacturing operation, and you’re about to give one of your staff and new assignment, only to discover they are busy with Project X., which you know nothing about.  What do you think your next step might be?  Darn right!  Call in the project manager for Project X. and explain who’s in charge, etc. etc.

So, next time around this project manager comes to you asking for staff assignments where he will need some help, but the work won’t start until eight months from now.  Who will you assign?  I sure wouldn’t want to make that decision today.  Staff assignments, workload, vacations, promotions, etc. clearly, that decision should be made much closer to the time the work will actually be performed.  Ironically, the need to have a name is often driven by the limitations of the software planning tool.  Computers like certainty, but the ideal workflow would involve assigning the department today, and the individual resource at some point in the future.  As long as we’re dreaming, let’s let the department head (not the planner, or the project manager) assign the resource.

Okay so we plan the work assignment to a department, and let the department head assign the resource.  Simple, right? Not really!  I was on a project once where we planned a large block of work for two separate divisions.  One division was ahead, so the trailing division copied their plans with appropriate staff reassignments.  Wow!  It was ugly!  The organizations were virtually identical, but not exactly identical, and this process resulted in blocks of work assigned to the wrong department!  Gee, what if we simply asked you “is this your teams work?”  And let you accept the work now but make a resource assignment later?  This way, we know we have the work assigned to the right team.  As long as we’re dreaming, how about giving you a way to give the work back to the planner, while we’re planning, perhaps with a note advising what team owns this activity.  This way, we catch the error, and correct, while minimizing rework within the planning process.  I have implemented tools that do this, and I can assure you the insurmountable planning of large projects suddenly becomes straightforward, efficient, and brutally effective.

Let’s review: For the large company where project work is not your primary business, plan the work as a project, but execute the work inside of your individual teams, or departments, within the larger organization.  Unless a dedicated team of staff will work exclusively on this project, this approach is absolutely essential.  Look what we’ve accomplished: planning using a cross functional team, and execution inside the silos of the existing organizational structure, with the individual resources and their direct supervisor responsible for the execution of each discrete process step.

It’s interesting to know how many ways I’ve seen this word and function interpreted.  To me, reporting is quantitative, developed from rollup’s of various done versus not done activity.  For those using older methods, I would include percent complete for the fewer larger tasks approach as this meets my quantitative criteria. 

Good reporting is Quantitative, not just Qualitative

I am amused, and horrified when I’m presented with progress reports in Word or PowerPoint.  In our shop, we affectionately refer to this as smiley face reporting.:-)

Sad but true, many believe this is the only way to effectively brief their executive team.  While I completely agree many software tools are incomplete in this area, I do not believe manual intervention and interpretation is appropriate or advantageous.  It adds cost, and of course the potential for abuse, but more importantly, it always adds delay.  The delay of a day or two might be manageable but a delay of a week or more is completely unmanageable.  I can’t tell you how many times I’ve seen private spreadsheets, punch lists etc. coupled with meetings and conference calls simply because the enterprise reporting tool does not provide timely updating to progress, and is no longer an active management or reporting tool, but simply an auditing tool.

I am amused, and horrified when I’m presented with progress reports in Word or PowerPoint.  In our shop, we affectionately refer to this as smiley face reporting.:-)

Sad but true, many believe this is the only way to effectively brief their executive team.  While I completely agree many software tools are incomplete in this area, I do not believe manual intervention and interpretation is appropriate or advantageous.  It adds cost, and of course the potential for abuse, but more importantly, it always adds delay.  The delay of a day or two might be manageable but a delay of a week or more is completely unmanageable.  I can’t tell you how many times I’ve seen private spreadsheets, punch lists etc. coupled with meetings and conference calls simply because the enterprise reporting tool does not provide timely updating to progress, and is no longer an active management or reporting tool, but simply an auditing tool.

The method I am describing is available today.  There is a cost, of course, for access to the tools, but that cost is already funded within your existing project.  How?  Two simple concepts:  (1) SaaS (software as a service) and (2) cost avoidance, allowing for shifting of funds from one purpose to another.  Software as a service is just a fancy name for buying access to an outside (web based) software service for a fee.  Think of this like renting access to a dedicated website that runs your project management application.  There are several major benefits in using this strategy:  Availability is immediate, rather than months of planning, hardware and software acquisition, integration, testing, rollout, etc.  This allows impact, or benefit to be immediate.  Also, rather than incurring all costs up front, this is a pay as you go approach, so, with an associated cost savings, the two costs offset each other.  In our experience this is always the case, so, the service is already funded within the project.  Just allocate some of the saved labor costs to the SaaS fee, and you’re up and running, live, and funded, within the project.  Where is the labor savings?  Simple:  All meetings for progress reporting are completely eliminated.  Meetings are still required, of course, but they take on a whole new tone.  Meetings are now for conflict resolution, not for progress reporting.  Progress reporting is now fully automated, to a live, quantified level with greater accuracy than was ever possible, at a lower net project cost.  Expect to save one hour per week from each resource assigned, and as much as 25% of each project manager’s time on a weekly basis.  These numbers are conservative and consistent across our previous experience.

Ready to get started? 

Please send me a brief description of your needs

Warmest Regards,

Joe Carapellucci

joe@projectbyweb.com