How can I convince my management of the importance of my involvement in other parts of a project?

Question

I am a software developer working in a project that involves two separate software systems which communicate with each other. I am primarily responsible for one of these systems, and my company hired a software contracting firm to create the other system. Once the contractors are finished with their system, they will hand the code off to my company and walk away. After that, it will be my responsibility to maintain the code for both systems, add features, fix bugs, etc.

We have done some testing to make sure the correct information is being passed between our systems, and that they are interfacing as expected, but I have no idea how the contractors have implemented their system. I don't know if they have used good programming practices or documented anything, and I don't know what kind of testing they are doing, if any.

This seems like a recipe for disaster to me because the code they hand off to us could be a huge mess and I can think of many potential maintenance problems that could be prevented if I could just be a little involved in their development process and see how they are implementing things BEFORE they hand off the finished product and walk away. However, my management does not share these sentiments and wants to believe that everything will be fine. I have brought up my concerns several times in the past few months, but to no avail.

It seems to me that, since I will be the one responsible for maintaining this software, I should have some visibility into the development process before it is handed off to me. I have been a part of software projects in the past that have fallen way behind schedule and failed due to similar situations as this, and I want to make sure this doesn't happen to this project. How can I help my boss see the importance of my early involvement in the system being developed by the software contractors?

EDIT

A few clarifications:

• My boss is a smart guy, but has very limited experience with software projects and has never been a part of a project this large and involved. I don't think he understands how much time and money can be saved down the road by eliminating design smells and bad practices early in the development process.
• There is a deadline, and if we wait until the contractor is "finished" to do our first code review, there will be no time for any significant changes.
• The contractor has assigned a single developer to this project, and there has been a learning curve for him. As far as I know, his code is not being documented or peer reviewed within his organization. So, I suspect there will be problems.

Answer 1

I tend to operate in the same way - looking ahead for potential issues and how to mitigate them a long way before they are an issue; mentally I think of this as "iceberg spotting", in that if you spot the iceberg early enough you can make a gentle course correction without the need for panic, and not lose to much in the way of velocity.

The challenge - as you are finding in this case - is that sometimes it can be hard to get management to adjust their viewpoint based on what you think might happen.

From what you have told us, its hard to know how the risks are being considered and managed by the project manager and the wider organisation a part of their project management cycle. You can see some of these risks, but the project manager is unconcerned.

I'd suggest there are a number of possible reasons for this (beyond simply an optimistic outlook!); two I have come across are :

• Change through crisis. In a lot of organisations it can be a lot easier to bring about change to deal with a real problem, as opposed to a potential one. Your manager seems to be aware of the issues, and might be allowing the problem to happen to bring about some wider organisational change - perhaps in the way that contractors are administered or used, by allowing the crisis to unfold.

• Confidence in the contractor. You boss may have good knowledge of the contractor, or the quality standards that were put into place as part of the contract to ensure the work could be handed over. There could be other unknowns, such as penalty clauses in the contact assoociated with non-compliance to agreed standards.

In this case, rather than suggest a solution, it may be better to ask the manager open questions as a way of raising your concerns. Its important not to do this in a confontational manner, and in an open way. Depending on how you work and the terminology you use, these might include :

'How much time is scheduled in the project plan for the code handover?'

'How long will the contractors be available for after we "go live" in case there are any issues?'

'Would it be possible to have a week or so "shakedown" run while the contractors are still on site to make sure there are no integration issues?'

'Shall I put together a suite of integration tests that cover the combined code-based, so we can verify the contractors work?'

I'd also suggest its well worth looking into the "causes of IT project failure" online. There's a lot of material available in terms of published studies that you could use to back up your concerns. For example, the Bull survey quoted on this link highlights that "communication between parties" is key risk factor to be mitigated.

Answer 2

That is really not your responsibility. I understand your concern and it could very well be that you will have to fix the mess the contractors made. But for now it is your job to develop your half of the application. It is the project manager and who ever set up the contract with the contractors to make sure that that half of the project works and meets requirements.

You can certainly suggest to your manager that you be involved in code reviews. But I would assume you have already done this before you asked this question. If not I suggest taking a direct approach explaining your concerns and that you are trying to act proactively. If your manager rebuffs the request do your half of the project and worry about supporting the other when it is delivered.

Answer 3

This is really all about how you position the request.

If you have a Project Manager, then I would ensure that they have a "transition period" on the books for the tail end of the project. If this has to go through your manager, I would position this as a future cost-savings and responsiveness measure. In both cases, though, your audience is going to see this as "additional work" that could push the end date of the project. You need to be able to demonstrate that this 'knowledge sharing' doesn't impact your ability to meet your deadlines:

Manager, I'm concerned about the transition period off of this current project. If we have an issue that needs attention in the first few weeks after the end of the project, we're either going to have to wait for me to get up to speed or pay the current consultants to address it. In the interest of cost-savings and proactively ensuring that I can respond to the needs of this project's end-users, I'd like your permission to spend 2-4 hours knowledge-sharing with the consultants. While I'm sure I could figure it out in a week or two on my own, just a couple of hours with the implementers should give me enough time to get my head around the system and make me feel significantly more comfortable when it comes time to make modifications. Based on current burn-down and outstanding tasks, this will not impact the currently projected end-dates.

Answer 4

We have done some testing to make sure the correct information is being passed between our systems, and that they are interfacing as expected, but I have no idea how the contractors have implemented their system. I don't know if they have used good programming practices or documented anything, and I don't know what kind of testing they are doing, if any.

Since you have no idea how the contractors have implemented their system, you should:

1. Check if there is a enterprise architect/tech lead in your project, who might have reviewed the design of both the systems and approved it. If there is none, then you need to get the design doc and review it and check if it fits into the overall enterprise landscape of your organization. If your experience is limited or you do not have much knowledge about the overall enterprise to review the design, then I would check with the project manager and suggest that the design needs to be reviewed and highlight the risks to the manager.

2. You can do your own checks on the code base of the contractor to see if they are following the same coding conventions, unit testing processes etc. If there is a continuous integration system which runs unit tests at regular intervals and then reports the results. Ifthey look OK and are consistent with the results of your system, then I would not worry too much. But if something is missing here, then I would highlight this as a risk to my manager and leave it at that.

I have been a part of software project in the past that have fallen way behind schedule and failed due to similar situations as this, and I want to make sure that doesn't happen to this project.

a. The situations that you mentioned here, did they occur in the current company and with the same contractor? If yes, then your project manager might already know about this risk.

b. How is your relationship with your manager? How long have you worked with him? How open is he in taking suggestions from a technical person suggesting him about the project risks (which he might already know)? So convincing your manager, depends on these softer aspects too.

My suggestion is to go with the steps 1 and 2 I have mentioned above and highlight risks to my manager if any. If your manager is convinced or not and whether he takes any appropriate steps to overcome the risks, I will leave it to him.