1

A colleague is putting together a PID (Project Initiation Document) to outline some issues with some of our IT architecture. She's a Project Management Team Lead, I'm an outside contractor brought in to a support an ageing system they have. This system relies in part on a second system from 2000. In her PID and other documents she repeatedly refers to it as being unstable and rapidly becoming more so.

To be clear, I absolutely agree with the aim of the project. The second system went out of the last bit of support in 2013 and it needs replacing in the firm. However this second system is no more stable or unstable than it was 3 years ago, or indeed 10 years ago.

I want to challenge her use of emotive wording in a technical document. What are some methods I could go about this and some wording suggestions I could make?

  • 5
    It sounds like you could be arguing over semantics here and may be overthinking things. If the system no longer has any vendor support available but remains in productive use, then I would indeed call that an unstable system that well become a bigger liability ("more unstable") as time goes on because the risk of issues coming up increases and the knowledge of that system (internally or at external consultancies) dies out. Have you tried simply asking this colleague what she means by "unstable?" – Lilienthal Apr 26 '16 at 10:18
  • 1
    Does stable have a well-defined, agreed upon meaning in this context? For example, we might define the stability of a server using metrics like uptime or response time. A user application that is unstable is usually one that crashes often or easily. – Brandin Apr 26 '16 at 10:32
  • 1
    @Migz A legacy system that cannot be updated meets your definition of unstable in my opinion as well as the classic definition of being unpredictable and failure-prone and that's why I mentioned that this is arguing over semantics. This entire question reeks of over-documentation. An analysis of whether a system is future proof shouldn't require a custom dictionary. But I suppose that this is neither the time nor place to start up a discussion on that. – Lilienthal Apr 26 '16 at 11:29
  • 1
    @agentroadkill I think the problem is that the old system is not actually unstable (i.e. it does not have a high failure rate). It sounds like the correct term is "maintenance hazard". I.e., the system itself is stable but if it fails completely you are toast. – Brandin Apr 26 '16 at 12:32
  • 1
    @agentroadkill Why not just say it is unmaintained, or say the vendor has dropped support for the product(s)? In any case, if it was my colleague I would probably only mention it if she actually asked for feedback, or if it was actually my responsibility to check over the wording of the report. – Brandin Apr 26 '16 at 13:51
3

I don't see anything wrong with telling her directly that you aren't sure about your word choice. There's no need to beat around the bush. I would write an email, something along the lines of:

"Hi Debbie, thanks for writing the proposal for a project that is long overdue. We will all benefit from an update. However, I'm a bit worried about saying that it's "unstable" - this isn't technically accurate and I would hate to see this thrown out on a technicality. You never know what management will pick up on. Can we meet up to talk about another word to describe the system? Thanks. Paul."

Because there is an implicit criticism, I'd say an email is the less confrontational way of starting the conversation, but it should lead to a face-to-face conversation. If you have experience of submitting similar proposals you could bring that up too.

  • Note: saying "I'm not sure" is tremendously better than saying "you're wrong". – keshlam Apr 26 '16 at 13:47
2

To be clear, I absolutely agree with the aim of the project.

Since you agree, don't challenge her at all.

Instead try to genuinely contribute to the system's modernizing.

Regardless how your system acts, fossilized systems should slowly and surely be removed. Especially when support is dropped.

It's a lot of work in the beginning, but afterwards it's really easier to go on with it.

  • 1
    By not talking to her at all about this she will risk repeating the same mistake over and over again. While in this case the ends justify the means. This will not be the case in other circumstances. Also, as an outside contractor, he is expected to deliver optimal quality work. This could reflect badly on him regardless of what the end result will be. – Migz Apr 26 '16 at 11:13
0

Ask her "Why do we do this project?" and when she replies that it's unstable and is becoming more unstable just ask again "Is it really?". At that point she will need to think about it clearly and admit that it wouldn't describe the problem correctly. Once she understands that the description isn't accurate you can counter her with a suggestion such as the following:

  • The system is no longer supported which increases the risk in case problems occur. The results of which we may or may not be capable of fixing due to having no support for this system.

I can assume that there may be more reasons, but as I read your question, this seems to be the most prevalent one.

It's important to keep asking questions about the PID. The PID is the core document to which nearly every question should be answered in. If the answers are incorrect or inaccurate your project will have a crooked base and may go into a unwanted direction. If you have a good PID, then any questions you may ask should be easy to answer and to defend in case you ask for her to elaborate on it.

If she insists on keeping it as unstable, ask her if the goal of the project is to make the project more stable, rather than more reliable and to reduce risks. If nothing works, ask for a second opinion from someone else in the company. possibly even your manager.

Worst case scenario, she will be as stubborn as an ox and tries to present it towards your manager. At this point it's 100% out of your hands. But I suspect that responsibility for the PID will shift towards you instead if it comes to it.

As a contractor you're hired to show your expertise and are expected to provide results. If you were to accept this PID you would be unable to show either. If in the end the manager still were to agree with her on the PID and the project were to fail due to this. You should have this documented that both she and the manager take responsibility for this part of the PID in case it goes wrong. (risk log entry)

  • 1
    I think your approach here is too aggressive. There's no point interrogating anyone. Also, your answer does not allow for the possibility of Jan changing his mind. His coworker may have her reasons. – JK39 Apr 26 '16 at 10:47
  • @JK39 You misunderstand the meaning of a PID. It's a document that you can defend against any kind of questions. If she's capable of defending her PID from these questions she should be proud. However if it can't, it can have serious consequences. The only way that you can improve a PID is to keep asking questions towards it. I ask the same questions to myself in order to write my own PID. She's literally writing a contract for this project. That's what a PID is. I might be too blunt, however this is not something you want her to repeat. It's a risk if she does. – Migz Apr 26 '16 at 10:56
  • 1
    OK, but I suppose what I'm getting at is that you seem to be anticipating a combative conversation, which is a big assumption. Also your use of the Socratic method could create a teacher-student dynamic that she might respond negatively to. – JK39 Apr 26 '16 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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