Discussion on:

Project managers need to understand lifecycle work

I would be interested in your views on how defined project lifecycles can be applied to the less definite "business initiatives", normally classed/disguised as BAU. Unless there?s a distinctive definition of a project, which can cover all aspects of change within an organisation then the BAU card will and can be used.

Hi Derek,
project is defined as finishing at some point (most do that but late;-) whereas BAU is an ongoing exercise. If you are not working in a project-only organisation (professional services, consultancy, etc) than project managers have to cater for this by allowing for a certain percentage of time which their team members are not available for project work - this gets very often forgotten.
I have also experienced clients where they forced everything BAU into projects, I would advise against this as it takes away the benefits of "project" work such as the timeliness of delivery.
hope that helps
Holger

Can you define/clarify your use of the acronym 'BAU' ? We have occassionally used the phrase to mean 'business as usual'. But, you refer to it in your reply as "a BAU", implying that it is something quite specific.

Sorry but this was based on my poor usage of the English language - humble apologies!

Hi Holger:

Your comment is very accurate. What I would like to know is how do you determine the "certain percentage" mentioned in your reply. How is it derived? As an example, when bidding on a project what percentage should be added on the schedule to compensate for project members unavailable for project work.

Thanks

BAKimmell

Sorry but I can only come up with the typical consultant answer: It depends
Utilization models I am working with have factors such as public holidays (differences by country, regions, religion, etc.), holidays (contracts), illness (I assume 1 week/year), administration (time for filling out time sheets), education (depends on company policy) attached to it.
You will find out how little time people really work...
And then you take off time for BAU... again higly dependable on the role (e.g. someone works in a customer call centre, you might get generic data)

hope that helps
Holger

I usually try and talk to the In Life Support people (who are usually the ones who are critical to delivery, but have the least time) and offer to backfill those I need with outside resource for the period of project time.

This has some interesting effects:
o enables me to have a legitimate call on their time
o lets their manager know if they have a single source of critical information
o BAU processes seem to be better documented for handover to contractor or
o As often happens the BAU resource will give up their time without having to bring in extra heads as they don?t want to have to handover to outsiders

That way BAU manager has to ensure that his work as well as the project work is covered.

I hope this helps too
Bill

is people picking the life cycle, then trying to hammer the project into it. It should be the other way round, look at the project pick the best lifecycle model.
Classic waterfall is a prime example, it rarely fits a project in the real world, most of those are better with iterative.

The only life cycle I can think of where PM activities aren't explicitly defined as part of it is RAD, which explains why it was an abysmal failure in practice.

Agile and spiral are the two I use most often. Defined deliverables and review points need to be adhered too whatever your lifecycle otherwise it's not being managed.

The trick with any IT project is to discover as early as possible, you are going wrong somewhere.

Tony,
for me two points are important:
1. The organisation must provide multiple lifecycles to the PM community. Problem with that is the workload associated with this (and the expertise required to establish, implement and maintain)
2. PM should be able to work in different lifecycles on the same project if necessary, e.g. waterfall to satisfy requirements like finance etc and iterative for the core of the project. Education and expertise are possible problems...

I tend to disagree with your statement about existance of PM activities in different lifecycles... IF they are included they cover usually the basics in administration and planning but are not sufficient to do a good job as a PM.

In our consulting firm, we use the ISO12207 framework to conceptually describe the overall software processes. ISO defines 14 macro-processes for software development, plus a few "organizational processes" such as project management.

For project magagement we use the PMI PMBOK Guide, which includes 44 processes and a bunch of outputs for initiating, planning, monitoring & controlling, and closng a project.

By splitting PM process away from all the actual delivery work (eg. BA, QA, architecture, development, user experience, etc.), and tailoring industry standards we gained a lot of understanding:

1) We understand the importance of having a formal PM - especially in the sales phase where most of the damage to a project usually happens (due to poor estimation and over-promises).

2) We learned that there is really one master process from which subsets can be applied to handle any situation. The PM Master Process and the SDLC Master Process. (Note: there are a few exceptions, where the lifecycle is dramatically different - eg. ERP solutions. I think this idea was pointed out already in this thread.)

3) We understand that we need different views of our lifecycle depending on the project type (customer, industry, technology, size, etc.)

4) We understand which job roles are needed for which types of projects. (Before, PM and BA processes were all combined into a single "lifecycle" document. This had the undesireable effect of us creating PM/BA job specifications and hiring folks who are "jack of all trades, master of none.")

5) Our customers recognize the names of the documents they receive, since we're using standards now. For example, there used to be a lot of confusion around whether the scope should be in the project charter, project plan, or functional specification. Depending on who was planning the project, you'd get a different document (and never in the same format as the previous project).

6) When things go wrong - whether identified during a project, or after it's closed - we can always point to the processes that failed. This allows us to manage risk much better and to improve over time.

The "lifecycle" in question is covered in general by the Systems Engineering Lifecycle".

Project Management has it's own lifecycle which is applied to whichever "piece" of the systems engineering lifecycle is within the scope of the project.

Think of a "design" project or a "decommissioning" project. These only cover a portion of the systems engineering life cycle but would fully exercise the project life cycle.

I my experience the inability of people to clearly differentiate between the two lifecycle models is the root cause of much of the wooly thinking and confusion around project work.

A key indicator is to look for instances where systems engineering lifecycle elements are included in the definition of the project lifecycle.

Before anyone says "But my projects are different and the systems engineering lifecycle does not fit my industry/technology/service" please check your understanding of the systems engineeering life cycle. It is universally applicable. If you havn't grasped that you don't understand the concept and principles fully.

Project Management manages the context. Systems Engineering manages the content.

Hi guys,
Please tell me How does project scope control apply in the execution phase of the project lifecycle only or is it influenced from elsewhere?