11

I know this is likely to fail almost by definition, but I don't really have an suitable alternative.

Currently we are working almost exactly the opposite way, with a 8 items work plan, but we are losing control over the work to be performed.

I have the material to come up with such plan ( we have spent 2 weeks or so looking at the requirements and we have so far a 300+ list of activities to perform )

Any advice would be appreciated

Zsolt
  • 11,928
  • 1
  • 27
  • 60
John
  • 111
  • 1
  • 3
  • 1
    Can you clarify, please: who has set the 300+ activities to perform, and how do these activities relate to the business requirements? (i.e. are the requirements being expressed in terms of the activities that you need to carry out, rather than the business outcomes?) – Iain9688 Sep 14 '11 at 06:17
  • We did ( I did ) The user gave us narratives of what he needs the system ( this is a software project ) to do. For instance: "login into a web page" we created 4 activities for that to be completed. a) Create the login page, b) create a database table c) create etc. etc. Does it make sense? – John Sep 14 '11 at 06:47
  • Does the customer say why they want this? – SBWorks Sep 14 '11 at 06:48
  • The functionality ? Or the workplan? Well the answer is yes to both. – John Sep 14 '11 at 06:50
  • Hi, is the client maybe saving you from bigger trouble. I'm just coming out of a project gone haywire like your clients last one and a hour-by-hour plan would have helped a lot.

    Of course the next step would have been to re-discuss the plan pretty much every 3 days, but we wouldn't have been so out of pocket nonetheless (it was fixed price).

    Of course a more agile and trusted approach will be a bigger win-win for both client and you, but maybe the step in between is this breakdown.

     – jdog Sep 14 '11 at 08:27
  • John, thanks for the clarification. I don't think I have an answer to your question, but I would make an observation that the cost in both financial and effort terms to monitor and report on progress could be very large, and perhaps outweigh the benefit, and equally, the customer will have to put in a lot of effort to make sense out of the information you provide, unless they simply use failure as a stick to beat you with. I can only wish you the best of good luck, and state that I believe that Pawel makes a lot of sense, especially in the final few paragraphs of his answer. – Iain9688 Sep 14 '11 at 18:19

5 Answers5

16

It seems the root issue here is lack of trust between client and your company. They don't trust you will deliver the solution, whatever it is, according to a general roadmap you have. I assume that you have one. What more they don't trust you know what you do in short term. Basing on what you wrote ("we are losing control over the work to be performed") it doesn't happen without a reason.

Anyway it this situation you can choose a couple of solutions, which with a bit of luck may end up in almost the same place:

  • Try to convince the client to more agile approach. I don't mean here "we know only 8 next work items which will be done" but rather setting up a general roadmap along with priorities, e.g. we aim to deliver the app on such and such date, general functions will be this, this and that, we have these other milestones and so on. Then you need some kind of proof to show the client you know what you do, meaning you plan your iterations or just a shortlist of the next n most important features but you can show how it brings you toward high-level goals stated in the roadmap. In other words you need product management or product ownership role on your side. Someone who would verify whether short-term tasks are aligned with long-term goals. If you're lucky you should end up with slight changes in the way you build software, yet effects of changes around (long term plan, product ownership) can be pretty significant.

  • Try to adjust to client's wish but do so in possibly most reasonable way. It is impossible to deliver reliable project plan going down to granularity of hours. Well, it is possible to build such plan but it won't survive the contact with the reality. If the client insist they want a fine-grained plan prepare the best possible, yet reasonable, plan you can. It probably means it will be fine-grained at the beginning and pretty coarse-grained at the end. However it still gives the client a pretty good tool to track your progress. I mean we can perfectly measure one-day slip when we think about the next week but if we discuss the next year? Come on, there are thousands of things which will change and the best thing we can do is to regularly fill the plan with more details as we go.

As I said both ways can end up in the same place. In both situations it is equally crucial to show the client that you are able to deliver what you plan as this is the only thing which will build trust to you and your software development and project management methods. If you fail to keep your word, don't be surprised the client will try to formalize plans as much as possible.

And of course you can end up with the client insisting they still want to have the plan done their way. Then you basically have two choices:

  • Do what they want, knowing it possibly is a piece of crap, and then live with it. It probably means rugged cooperation with the client from now on.

  • Walk away, stating that you don't want to work under such conditions. Contrary to many others I am well aware that this option might actually be impossible to execute, although I know companies which do that.

Pawel Brodzinski
  • 19,896
  • 56
  • 131
  • Thank you Pawel. Yeah, there is something about that. There was another project in the past that failed because they didn't have this detailed workplan and they don't want to make the same mistake this time, at least that was what they said. I have splitted the whole work into 4 milestones ( 3 weeks each ) and we reached the first milestone with a delay of 2 days, but since it is 12 weeks project, they are very worried about if we are going to finish it on time or not and/or to know exactly what we are doing next week and so. – John Sep 14 '11 at 06:59
1

I would think about looking at a backlog of things to. So, think about big bits of work, their parts and further the work that will be done in the next iteration/unit of time. You've lost the client, that is obvious, but you can get them back by building trust which you do like this: say you will do something and then do it. Repeat that process until all the work is done.

So, top of my head, prepare a meeting and invite them to it. Say that you feel that trust levels are low as per the request for a detailed list. Tell them you plan to do something about that and explain why the detailed breakdown is silly (you had better do your homework here as your articulation has to be spot on). Then tell them what you will be doing in the next unit of work, then make sure you do it. Repeat this process.

Ask this question: do they want to suceed? If they do, then your job is to coach them through this. Start that by turning things inside out and leading this. Don't let this client bully you for everyone's sake.

Jamie.

PS - good luck! Things will clear up.

Jamie
  • 31
  • 1
1

You have indicated you have a 12-week project with essentially three milestones against which to measure. At the 2nd milestone you would have exhausted roughly 66% of your project before you can make an assessment how you are doing. Your ability to recover would be seriously compromised! I am with your customer: you need way more detail than what you are proposing. I'd take a measurement weekly or semi-weekly for such a short duration, which means you need to break the work down further.

Hours is probably too much but that might be a reaction to the fuzzy approach you suggested.

David Espina
  • 37,143
  • 4
  • 34
  • 91
1

Sounds like things are getting out of control and the client knows it.

Do you have a professional project manager or even a designated project manager to manage the work?

Mark Phillips
  • 8,849
  • 4
  • 30
  • 57
1

I've dealt with this situation and I agree with Pawel that that problem is lack of trust. In our case the lack of trust was due both to a failure to deliver in the past and to the client's personal need to feel in control. Despite our best efforts, there was a lot of tension between the development teams (2) and the client for the duration of the project. However, we maintained enough communication and respect that the same teams were awarded another contract from the same client. That was a mixed blessing, but that's another story! :-)

Has the client seen your list of 300+ activities? It might be reassuring just to know that you've broken things down into more detail than the 8 items in the current plan. It may also help to indicate whether each task is low (~1 day), medium (~2-4 days),high (~1-2 wks) or very high effort; again, that shows that you've thought a bit about the details, and it assures both the client and you that all of these activities can be accomplished in the time allotted. (Or it shows both of you that they can't, in which case the problem is different.)

Try offering the client options for how to proceed. All of the options should address the client's concerns in some way, and you should be frank about the benefits and disadvantages of each option. For example :

  • We can make a plan that assigns each of those 300 activities to a specified week, and at our weekly meeting report on the ones that were finished. Advantage: a full, clear plan from the start. Disadvantage: you spend a lot of time making the plan, and a lot more time each week reorganizing the plan to account for unexpected issues that have arisen.
  • We can make a plan that assigns tasks for the next 2-3 weeks, and leave the other tasks all listed, assigning a new week's worth of tasks as we finish each week. That way the client has a rolling 2-3 week window of plan, and you have more flexibility to organize as you go.
  • Rolling window greater than 2-3 weeks but less that the whole duration of the project.

You may think of other kinds of options that are more appropriate to your situation and to the way your team works, and you may have to adjust as the project proceeds, depending on how long it is. No matter what your options and decision are, you need to make sure the client has regular reports of progress and a confident, clear explanation for why you fall behind, if you do.

Linda Schmandt
  • 371
  • 1
  • 7