Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

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.
share|improve this question
1  
Seems to me you've done everything you reasonably can to convince management that your involvement is important. However it's ultimately managements decision; as an employee you can either accept the decision or start looking for other work. Don't beat a dead horse even if you're right. –  Stephen Dec 16 '12 at 16:45
    
@Stephen you're right, it's just hard to accept what I think is a bad decision that puts a project that I care about at risk. I really want the project to succeed and I see this problem as a huge threat. –  Jefferson Dec 17 '12 at 14:00
    
Have you communicated those concerns in your question to your manager? what was the response? –  ReallyTiredOfThisGame Dec 17 '12 at 14:37
    
@Chad I have communicated these concerns to my manager and his response is along the lines of "I'm sure we'll be able to fix bugs and add features in whatever they give us." At this point, I stop pushing back so as not to be confrontational or insubordinate, but inside I'm thinking of how dangerous his assumptions are. Money is tight at my company and the finance people are not going to like me spending weeks and weeks refactoring inefficient code. In fact, it may even reflect badly on me. It just makes so much sense to nip the potential problems in the bud now. –  Jefferson Dec 17 '12 at 14:54

4 Answers 4

up vote 7 down vote accepted

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.

share|improve this answer
    
I gained a great deal of insight from your answer. Thank you! –  Jefferson Dec 17 '12 at 13:22
1  
This blows Chad's answer out of the water. –  Fernando Dec 17 '12 at 15:15
    
@Fernando - Both answers are equally valid, IMHO. If the OP can just "let it go" this may be the wisest course of action, especially if the "iceberg" is too close for the ship to turn. If they are wired a bit like me(!) and find it equally stressful to do nothing, then "coaching" questions of the type I have suggested may help. If the OP is correct, the most important thing is not to go down with the ship.... –  GuyM Dec 17 '12 at 18:28

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.

share|improve this answer
4  
It's his responsibility to inform management of potential problems that he sees that they may not. They are free to disregard his advice, but when the contractors deliver a big ball of WTF and managements asks for changes, at least he will have warned them. –  kevin cline Dec 15 '12 at 18:13
    
@kevincline - I do not disagree if there is some sign of problems. The OP seems to be complaining not because he suspects there will be problems but rather than he has been excluded from the development by the contractor. If possible I think having him involved in the code reviews would be great but as a contractor I am going to raise the rate if the company wants to come in and have a say in the development. It will create problems on the contractor end having the customer telling them they are doing it wrong. –  ReallyTiredOfThisGame Dec 15 '12 at 22:35
    
a good comprimise is probably to have a code review before accepting delivery of the code from the contractor. –  ReallyTiredOfThisGame Dec 15 '12 at 22:36
2  
Serious problems are more likely than not. The only way to change that estimate is to get an early look at the work in progress. –  kevin cline Dec 16 '12 at 19:09
    
@Kevincline I suggest you create your own answer to say that then. It appears at least one person agrees with you –  ReallyTiredOfThisGame Dec 17 '12 at 5:51

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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