Should changes be treated as Project Issues

[wenreg]

Hi,

Looking for some thoughts on whether the changes should be logged as Project Issues (as described in Prince 2). I am heading up a change control process for a programme and some of the Project Managers insist that the changes are logged as issues and managed as part of the issue management process. However I am of the thought that the change control process is separate and distinct, i.e. captured in a Change Log, raised using an Request For Change template etc.

Any thoughts on disadvantages or advantages of both schools of thought?

 

[LNBruno]

I am inclined to agree with you.

To me, issues are items that interfer with (prevent the flow of) the current plan. For example, not having a database created is an issue.

Changes are items which are modifications to the current plan. For example, deciding to switch from SQL Server 2000 to SQL Server 2005 is a change.

Issues typically impact the plan by means of extra time or expense. Changes may or may not impact the plan because they may be included as part of the current plan or pushed off to a "next release" list -- the decision typically made if there is no extra time or expense.

< M!ke >
[small]I can say nothing, which is cowardly, I can lie, which is immoral, or I can tell the truth, which will upset people. - Tiki Barber[/small]

 

[johnherman]

Changes, like issues, should be logged and reviewed by the steering committee. And a change which is not deferred can impact the schedule and introduce risk just like an issue, but I agree with the other answers (so far) that they should be treated separately. I think the main difference is that issues MUST be addressed, while changes can be deferred. If a change is mandatory, I could see the difficulty in distiguishing it from an issue.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright

 

[ProjectGuru]

A change may be introduced to resolve an issue, but the two should be captured separately, as a change can be related to anything, sponsor wanted to move into a different direction, increase in budget or scope, however an impact to schedule would be an issue and should be tracked and monitored as an issue.

Where a change is introduced to resolve a change however you should reference the issue in the change request.

 

[JedSimms]

An issue is within the mainstream of the project

A change is an alteration to the project that may impact its purpose and value

So, you are right to treat them as separate items

The only caveat I would add is that changes need to be seen in terms of their potential impact on the project's value proposition rather than just on time and cost.