26

I work in a small IT department (4 people), and two of the 4 of us are software developers. The company is behind the times in terms of IT solutions and technology in general. So my coworker and I are developing software to ease paper and pencil documentation, product tracking, cost savings solutions, and QA solutions and tracking. The other developer and myself work really well together and we are very good at making the software that is requested from the higher ups.

Our problem is that we get a project to 98% completion and our manager comes to us and informs us that our focus is now to be shifted to a new project or to go back to working on a previous unfinished project. Since these focus shifts come from a top tier boss we don't have much choice than to shift focus. But being thrown between new projects and having to revisit and pick up our thought trains on old ones months after we've left the project is becoming really troublesome. Myself and my partner are at the point where we are becoming jaded and we don't work nearly as hard as we used to on projects. Because we just know that we won't get to finish it. Add to that, our manager telling us that it appears that we aren't working because we haven't pushed anything out and that we are making the department look bad. It's just a really weird cycle that I think I'm the only one who sees it.

So, I'm here to ask you fine people if there is something we can do as developers to change the status quo? We've brought it up to our manager who has basically told us that it's just the way it is. Is there a way we can help keep the higher ups focused on current projects and not like kids with ADD who can't keep their mind focused for long? I understand that they are excited at what these solutions can do for the company but they just can't grasp the concept of the process of concept to completion. My partner and I would really like to get to a place where we can complete projects and implement what we design.

|improve this question
  • 1
    What have you tried so far? One conversation with a generic "that's how it is" is not the same as setting up a meeting with your managers to talk about the strategy and vision for the coming year / project(s). Did you just sit there and take it when he mentioned you're not pushing out anything new? – Lilienthal♦ Aug 4 '17 at 12:05
  • 1
    What are you using to track your tasks/projects and is it visible to MGMT? – Mister Positive♦ Aug 4 '17 at 12:14
  • We have IIP tracking but the IIPs never account for focus switches or any of these on the fly changes that get thrown our way. So according to the data we aren't meeting deadlines, so it looks bad on us. – Noble-Savage Aug 4 '17 at 12:27
  • 1
    Is this top-tier boss aware of the projects and their benefit to the company? Has your boss spoken to him on your behalf (and on the behalf of the beneficiaries of these incomplete projects) about the importance of completing the projects? Are there any status updates being pushed up the chain about projects underway and roadblocks that are preventing completion? – alroc Aug 4 '17 at 13:00
  • 1
    @Salmononius2 The powers that be have seen the benefit, and are now constantly asking for new things. It seems after every meeting they have a new request comes in. Upper management is very keen on these solutions but they don't understand the process enough to prevent a pile up of projects. Nor do they understand the time involved in creating some of the things they are asking for. – Noble-Savage Aug 4 '17 at 20:12
73

As a corporate VP once told me, "sometimes you need to let them feel the pain".

In other words, you need to let them feel the consequences of their actions. Since you said that they have no concept of the process from concept to completion, involve them in every phase. Arrange launch meetings, proof of concept meetings, prototyping meetings and any kind of meeting you can think of to show them that you don't just wave a magic wand to get things done.

When projects are canceled or put on hold, make sure that there is a "ramping down" meeting so that they know what is involved in shutting down a project, even temporarily. Then, when they say go back to it, schedule a re-launch meeting.

Give them some of the pain, but do it as part of the process. The reason they are so willy-nilly about jumping from project to project is because they have no part in the process. Involve them in the process to where their time is taken up by the consequences of their actions and their actions will change.

The point of this is not to be punitive, but to get involvement and understanding. They will never understand if they are not involved.

|improve this answer
  • 18
    @Korcholis It's not a "teach them a lesson", it's getting them to have skin in the game. I am editing for clarity – Richard Says Reinstate Monica Aug 4 '17 at 15:24
  • 2
    @Korcholis No solution is universal. – Richard Says Reinstate Monica Aug 4 '17 at 15:31
  • 1
    @Alexander isn't that cutting off your nose to spite your face? – Richard Says Reinstate Monica Aug 4 '17 at 15:53
  • 2
    Is this a gender-neutral "they" referring just to the manager or are you including upper management as well? – Lilienthal♦ Aug 4 '17 at 16:03
  • 1
    @Lilienthal including upper management, as they seem to have the problem as well, although the inclusion of those people in the meetings would be less often. Still, skin in the game reduces the pain. – Richard Says Reinstate Monica Aug 4 '17 at 17:29
4

I'd extend the project plan past the delivery date if possible. Usually "follow-up" or implementation verification is overlooked or not done at all mostly because it is not planned. Implementation verification is actually one of the most crucial steps, because processes hardly ever work the same in practice as in theory. To plan for implementation verification or follow-up you would need to identify the metrics you will be testing up-front in the planning stage as well as what the expected value of these metrics are to ensure implementation was effective. This step is usually scheduled atleast a month after implementation; so the customer has time to work through their own adaptation issues.

If this cannot be done or if you still keep getting pulled off at the end, then a more agile approach may be necessary. Agile in the sense, that you release the product to the customer in several stages, but each release works and could be used by itself. Then each iteration adds more functionality and "bells and whistles". That way the customer atleast has something that is functional (even though it may not be complete) and usually if they start using it they will pressure your manager to allow you to finish the project in full.

If neither of these work then just keep open communication with your customers and maybe they can pressure your manager into letting you finish the projects.

|improve this answer
3

I live a similar situation; sometimes I have projects that are about to finish i.e.: being tested, and when it comes to user acceptance tests it can take maybe 1 or 2 months when they come up with changes so I have to pick it up again.

Or projects that are not prioritized, so I look at them only when I have free time so I work on them once in a while. The only thing I could do to help with this situation is to focus on write down some comments, not just on the code, but what is the situation I'm dealing with, or what are the next step I have to take, so when I have to return to that project I'm able to pick it up faster.

As a developer, sometimes there is not much you can do to improve management (primary because it's your manager's job to do that). You just have to assume that priorities change frequently in some business or just because the owners suck at planning.

|improve this answer

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.