Different organizations are different!

For some companies, “projects” are one-off activities separate from their core processes, or basic business, such as making [...]]]> 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.

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

How much detail is the [...]]]> 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 [...]]]>  

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.

Sad but true, many believe this is the only way [...]]]> 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.

Reduce Cost, Reduce Risk, and Improve Quality, all with absolute certainty you will finish on time!

If you’re tired of surprises and disappointments and settling for less, you’ve come to the right place.

Reduce Cost, Reduce Risk, and Improve Quality, all with absolute certainty you will finish on time!

If you’re tired of surprises and disappointments and settling for less, you’ve come to the right place.

I’m Joe Carapellucci, a career registered professional engineer, with 25+ years of hands on experience behind what I’m going to share with you here….

The problem isn’t “better planning” or “better execution management” or “better reporting” …  it’s all those things, but more…

The problem is the way we do those things…

            Spreadsheets, email, planning software, Gantt charts, and meetings …

… all great tools 

…but just not good enough!

What I’m going to share with you in the next few minutes will change the way you look at managing projects… forever!

If you are the project manager, your life is about to get easier…  You will be able to manage more work, in less time, with a better outcome.

If you are the project executive, your nightmares are over…  Cost and schedule overruns… failed outcomes…  Gone!  Sounds just too good to be true, but I absolutely assure you if you hear me out, you will agree.

I’ve managed teams of 800+ (more on that later) where we absolutely had to finish, and absolutely had to assure quality.  Is that possible? The client thought their work would take 2 ½ years… we got them DONE in 9 months!  I confess this was a spectacular example to the methodology I’m about to share, but every engagement produces a cost and/or time reduction of 25% or more, all while improving quality.  Even teams as small as 5-10 people can see immediate benefits. 

Please take some time to digest this site, and contact me personally with any questions you have. 

To Better Projects!

Joseph D. Carapellucci, P.E.

joe@projectbyweb.com