Should a project sponsor have an access to Issues Tracking System (call it a "bug list")? If yes, how do you manage a potential conflict between sponsor's expectations of bug-free quality and a list of bugs he/she is seeing?

  • 1
    I don't think that any serious project sponsor/client could expect a bug-free system. The problem, I think, mainly about authorization: how much should the sponsor see so that he doesn't get mad about things he doesn't know. Commented Feb 15, 2011 at 16:36

8 Answers 8


The project sponsor should absolutely have to the issue list. This is necessary to ensure a common understanding of issues and facilitate communication which is important to maintaining a good relationship among all stakeholders.

To manage a sponsor's expectations it is important to include in your issue list:

  • Severity: High/Medium/Low. Only High severity issues are showstoppers.
  • Impact: If the issue is not resolved, what is the impact on the deliverable. Also equally as important, if the issue needs to be resolved, what will is the time/cost impact.
  • Usual items such as owner, target resolution date, etc.

I'd argue the business sponsor has a right to know the current state of the project and what the known defects are at any given point. If the sponsor expects bug-free quality, and there are bugs in the product, then the sponsor deserves to know that these expectations are not met. As far as that aspect goes, I wouldn't say there's a conflict of interest.

I see other problem areas, though. If the project sponsor is allowed access to the issue tracker, then everybody involved should know that. Developers might employ a language internally that they would not use in a system exposed to the sponsor.

Other than that, it usually interrupts the developers if the sponsor is allowed to add issues, and set priorities. The sponsor and project manager might have different opinions about what is defined as a bug and what is a change request, and such discussion should be held separately. For these reasons, I wouldn't give the project sponsor write access to the issue tracker.

  • 1
    I have some similar experience about this situation. Actually, I agree with you that giving them the right to create issues may causes lots of trouble; but in fact, I think we should allow them to comment on existing issues. In this way we would know if they have any problem. Commented Feb 15, 2011 at 16:32
  • 1
    Regarding the issue of developers employing a language that they would not use if exposed to sponsor, I ask team members to ensure they always use a language that is appropriate. Anything (project documentation, sandbox systems, test databases, etc.) can come under audit at any point in time so it is better to be safe and prevent any issues related to data privacy or political correctness. Plus it saves embarrassing situations like silly information appearing by mistake in a document or a system shown to customers.
    – Angeline
    Commented Jul 26, 2011 at 14:46

The project sponsor doesn't need to see the issue list while the deliverable is being developed. It is your job, as project manager, to take care of the project -not the sponsor's.

This kind of visibility into the process can lead to a lot of wasted time trying to explain details to someone who doesn't have experience in the specifics of this type of project. It also can give the impression that you are trying to offload your responsibilities onto the sponsor e.g. "you saw the list, Mr. Sponsor, and you didn't say anything about x,y or z."

However, once the project is complete the sponsor should have a full accounting of where the deliverable meets the requirements and quality standards -and where it doesn't.


I am having a hard time imagining why you would not want to do this?

I am going to assume that you are using some form of Agile development, maybe I am wrong and if so sorry.

Bugs or defects exist only outside of an iteration, meaning any issue discovered within an iteration is corrected or it is discussed with the sponsor and he/she agrees that it ok to ship or not. If not then the story is not shipped and it is reprioritized for possible acceptace in the next iteration.

Without complete visibility into the defects, how does the sponsor make informed decisions on the priority of issues in the backlog.


Yes, though there should be a way of making an issue private or a comment private so that developers do not fear being honest.

"It's a bit of a hack, but we think we can get away with storing the password in plain text for now", while not good, is better than not mentioning anything. The PM can still see that and decide whether to take action.


The answer in terms of giving access to the sponsor is yes since the sponsor pays for the project and (under standard project contracts) owns what is being produced as part of that project (including project documentation like an issues list).

I think the key however is in understanding why your sponsor wants to have access so you as a PM can offer him/her the best solution to meet his/her needs and expectations. For examples:

  • (s)he may want to see the issues because currently there is no visibility on the level of quality of what is being developed. In this case, it would be more efficient for you agree with the sponsor to report regularly on the level of bugs than your sponsor going through an issues list by him/herself.
  • perhaps there is an issue of trust; the sponsor is being told everything is going well but heard a comment that the system if full of bugs so wants to have a look at the list to form his/her own opinion. In this case the PM should address this with the sponsor and ensures that communications are clear and straightened.
  • maybe the sponsor is naturally curious and in fact very keen to understand how things are being done, which is a positive thing, so access may actually help to keep him/her involved.

If you agree to give access, make sure your sponsor understands how to use the system and that your team knows about it. I believe in most cases read-only access should be sufficient unless the sponsor actually has a agreed responsibility to identify or manage issues.


If the sponsor requests access, provide it. If not, don't. There is a huge difference between a working tool in which all kinds of un-scrubbed data are going in and out and a client-ready report. There is already a very human resistance in the escalation of issues and risks, as if by doing so you are advertising your inability to manage things. We all know intellectually it is quite the opposite; however, the resistance continues. If your client has access, my bet is that resistance will be exacerbated. Further, what is supposed to be your working tool will become a client-ready deliverable. You will see your issue management (and risk management) capability come to a grinding halt.

Do not confuse what I am writing as if I am suggesting you should be withholding information from your client. I advocate running as transparent as possible; however, there is a naturally applied filter you use during the escalation and reporting process. Not a filter to hide things the client should know but a filter to hide things about which the client does not need to worry.


This is a great question. On the one hand if the issue tracking is in the hands of a sponsor who will pick through each and every bug and add comments, call you and ask for status on a specific bug (when it's right there in the tracking tool), copy and paste details of the issue into outside emails to other stakeholders and create bad blood...then he/she probably should not be allowed access. But then, if you have a sponsor like this then you'll have headaches throughout the project for other reasons.

In general, I agree with those who said that the sponsor should be allowed full access to the issue tracking tool, and in most cases these people wouldn't even have the time to pick through each issue. But, if he ever did want to get more information on something, the details are there for him. Access to the issue tracking system should be granted with the understanding that the project manager makes decisions regarding priorities unless the sponsor is consulted specifically. Also, the sponsor should understand that any communication should continue to go through the PM, if he posts notes to the developers directly through the issue tracking tool, this will be much less productive.

Like some who mentioned, it would be ideal to have control over what issues the sponsor sees. LiquidPlanner is an excellent option for those who want this ability, the client portals will give the team control over what the client/sponsor can see and not see. This should help create a happy balance for all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.