Boss came and said "The system is broken". Would this be a project?

Question

I am preparing for the CAPM exam and following Rita's book.

But I couldn't figure out whether or not the above would be considered a Project.

It is also written:

Of the thousands of students RMC has taught, very few came into our classes understanding that you must first take what you are given and organize the work into appropriate projects. The project planning process will produce schedules and budgets. Can you schedule "fix it" if you do not know what is wrong? Of course not, so there are at least two projects in the previous story.

Why would there would be two projects?

Answer 1

Sounds like it's just a way of teacher's teaching style.

They seem to imply, in basic terms, any non-repetitive task can be called a project.

In the book's case, from what the question includes, finding the cause of the problem and learning the details of the problem is the first project and solving the problem is the second one.

On the other hand, if there is a problem somewhere. It can belong to an already existing project. And if that project is closed a new "fix" or "maintenance" can be scoped for that closed project.

Answer 2

All tasks are projects.

If you start to plan "Fix the problem", you're going to fail. If the problem is "Someone has unplugged the server", the WBS is going to be short, the quality tests are clear, etc. If on the other hand, the problem is "The server uses code that relies on a windows 98 library, and the programmer who maintains that library just retired and moved to Tahiti."The project is to migrate the codebase to something maintainable. The WBS is going to be much more complicated.

Personally, I think the problem is wrong. I think you need two projects, but they're different.

1. Activate the Disaster Recovery plan; determine the impact of "broke" on operations and activate the portions of the plan that include work-arounds. Estimate the time to return to operations. Brief the appropriate people. THis should all be in the disaster recovery plan. At the same time I'd document the issue and begin the fault analysis - because that will affect how we handle the rest. (Arguably, this is operations activity, not project activity, but in every environment in which I've worked, I've been responsible for both.)

2. Charter a project with two deliverables. First, a diagnosis & options on what needs to be fixed. What is the root cause of the failure and what are the options to fix the failure. Second deliverable is to produce, test & integrate the fix & turn over to operations.

Answer 3

A project is any amount of work which has a defined start and end. That being said, all projects have some amount of uncertainty at the beginning. So, in theory, the scenario could be considered as a single project: The end-point being 'when the problem goes away.'

However, it could also just as easily be split into multiple projects; the first of which having an end-point of 'what all of the problems are has been figured out.'

At which point you then have one (or more) projects that have end-points of 'Problem(s) have been fixed.' The advantage of doing it this way is that you have more knowledge at the beginning of starting the secondary project(s) and are thus better-able to plan at their beginnings.

Really, though, there's no difference between that and just starting with the original, vague project of 'fix all problems' and adapt/improve the plan/schedule as more information becomes available. Just because a project has an end-point doesn't mean that end-point cannot move.

(Assuming, of course, you are in an at least somewhat Agile environment.)