10

I am a programming/engineering freelancer working as a consultant for a mid-sized corporation. This mid-sized corporation has many clients, including a very large financial company (one of the top 10 financial companies in the world), who we will call "Client X". Years ago (before I started working here), my client created a custom fulfillment website for Client X.

I was originally hired to simply implement a new design over the website's existing infrastructure, but soon, I was being given new tasks - bug fixes, small enhancements - and then larger projects - new applications for the website, etc..

The majority of these tasks and projects have been managed using very rudimentary spreadsheets, email communication, and the occasional meeting. I have continually asked for Functional Specifications and/or Business Rules documents from Client X, but they never respond with either. Instead, I'm given a list of one-line tasks/projects and deadlines for each (which are usually unreasonable).

In addition to this, Client X rarely helps with any User Acceptance Testing, and instead expect me to simply take their requests, create them, and deploy and have everything work exactly as they requested.

When bugs occur, their feathers get very ruffled. They complain about the bugs, and about the time it takes to fix them, etc..

Now, I know that as the sole software engineer for my client, I am responsible for the bugs. However, I feel without proper Project Management, it is more difficult to create bug-free code. As a result of lack of assistance from Client X, I've had to make myself responsible for performing all of the following tasks for each project:

  • Writing Functional Specifications
  • Creating Mock-ups
  • Writing Technical Specifications
  • Programming
  • QA Testing
  • User Acceptance Testing
  • Deployment
  • Bug fixes
  • Project/Task Updates to the client
  • among other things....

Now, don't get me wrong, I enjoy each step of the process - I'm a perfectionist, and I like to be organized. However, I have to admit, that I'm not a great QA or User Acceptance Tester. I'm not a "normal" user of the website in question, so I can't think of every scenario to test. Also, the time it would take to properly test each feature takes away from time that I could be working on other projects for Client X.

It's a catch 22: they want their tasks/projects done quickly and bug-free, but they don't realize that those two things don't always exist together.

The first step I've taken is to start writing Testing Scripts, and to run through these for each task/project I work on.

But, there are drawbacks here as well. I'm being paid as a Programmer/Software Engineer. I have no problem being paid my existing rate to test applications/features, but it seems ridiculous to me to pay me as much as they are for this aspect, when they could be paying someone a lot less (idk, $15-20/hour?) to be a tester. Client X complains about the financial implications of me working on bug fixes, but to me, it would just make sense to hire a tester for a lot less money to run test scripts, and free up my time to write code.

I've tried explaining these things to my supervisor, who is 1. the liaison for Client X 2. the original programmer for the website, and 3. a VP for my client, but he sticks to the old adage of "the customer is always right", and thinks that if they don't want to write Functional Specifications and they don't want to help test and they don't want to use proper Project Management, that WE have to deal with it.

So, what are some ways I can "deal" with this environment/client?

  • What are the formal agreements between parts? Being very superficial, it seems OR a bad written contract OR a contract being broken... – Tiago Cardoso Apr 24 '12 at 17:11
  • Decent testers earn as much as decent devs, and are far rarer here in the UK. Don't know what the situation is in the States, but I'm guessing you get what you pay for. – Lunivore Apr 24 '12 at 17:45
  • Not sure of any formal agreement. If there is one, it was drafted/accepted years ago, and I highly doubt there is any language regarding them following any kind of Project Management protocol. – Eric Belair Apr 24 '12 at 20:52
  • I think if you've written a functional specification you should get the client to literally sign it off. Then when they report a bug, you can point to the spec, which they signed off on, and proceed from there by either formally changing the specification or dismissing the bug report (or just fixing it if it is legitimate). I emphasise that this is for clarity of communication, documentation, maintainability and so on. It's not to try and catch people out and blame them for problems. – jhsowter Jul 24 '12 at 1:53
  • It should have been made clear from the start how you want to work and whether they accept changes at that level or not. if you did not specify these types of things, then I think you are expected to work within their bounds. Of course you could use some sort of management software on the side for yourself as long as it doesn't go against any kind of IP policy, but don't expect them to conform to you unless you made that clear to them beforehand. – agent provocateur Jun 1 '18 at 20:24
3

My advice would be to adopt an Agile/Iterative approach.

Depending on the complexity of the system and the changes you're making, it might not be necessary to employ a full, traditional Waterfall methodology.

However, make sure you have adequate source control and some sort of change tracking system (even if it's just a spreadsheet for now).

If what they're asking is unclear, ask more questions until you understand it, then make the changes.

Explain to them that you'll release early and often, and will test the software yourself, to the best of your ability.

From there, it can be the end user's responsibility to verify that what you've done is actually what they wanted.

With a short release cycle, you'll be able to take that feedback, turnaround the changes quickly, and make them happy!

I put together a whole mini-site with some additional tips that might also be helpful: http://doingitwrong.jasonhanley.com/

  • Frequent iterations can be a challenge in a team of only 1 person. If you're releasing weekly, a team of 1 is going to implement a lot less than a team of 2 or 4. You run into the problem of either not having enough new stuff in each release, or having to make the iteration much longer. – jhsowter Jul 24 '12 at 1:43
  • @jhsowter depends wholly on the release process. if the release process is overburdened with a lot of overhead, then releasing frequently isn't going to happen much nor is there any benefit to it. As a team of 1 developing and managing an enterprise management app for a 15k+ employee company, I made the release process to be less burdensome and made it work for me and my situation, and when I'm deep in a development cycle, I release frequently (1+/week). of course its all situational and task/project dependent as well. – agent provocateur Jun 1 '18 at 20:27
2

You have more issues here than just a missing PM method. But then again, it sounds like this is the way your client and client X have been operating for "years." I am getting the impression they do not want to invest a ton of money in the capability you build and perhaps it is just cultural to complain and complain.

Bug free delivery of anything is impossible and, unless Client X are staffed with monkeys, that notion is known. So I get the impression they just complain as a way of managing their vendors.

I think the likelihood that you will get any change here is quite low. It seems this set up is the level of capability and maturity they want for your area, i.e., the level of investment is consistent with their expectations of return.

2

"What are some ways you can 'dea' with this environment/client?" Quite simply - learn to do it their way.

While I understand your frustration, especially as a perfectionist myself, the fact is you're a third-party hired consultant. Your job is to do what they hired you to do, and to do it within their environment. 'You' have to adjust, not them.

As you've pointed out, the two companies have a history, and good or bad, right or wrong, it works for them. So you're not going to change it.

So as David suggested - accept that this is how they do business, and learn to work within that model. Just don't expect to get them to change their methods.

And maybe you'll get lucky along the way and at least get them to adopt 'some' of your suggestions.

  • I think that @eric-belair has been doing it "their way" for some time, which is exactly what has lead to these problems. Unless you're content to keep making the same mistakes over and over again, then it's time to try and introduce some project management techniques which will avoid recurrence of the same issues. – jhsowter Jul 24 '12 at 1:46
  • 1
    Perhaps, but as he said - he's a freelance consultant. He has a better way of doing things, but both the company he's contracted with and the client don't see a need to change. It's their decision. As a contractor he has a choice whether to continue with the client or not. But it's not his role to push for change when A) that's not what he was hired for, and B) they don't want it. – Trevor K. Nelson Jul 25 '12 at 16:33
1

It sounds like you've got several different things that you would like help with. I'll try to give some guidance on a few of them, but the basic answer is to start collecting metrics (if you haven't already) and present your information with real $ numbers attached to it.

1. Testing

You may have already gone down this route, but if so I didn't see it in your question. Have you tried to put together the business case to your supervisor that it is worth hiring a tester? It sounds like Client X doesn't want to hire a tester, but what about your direct customer? Can you put together the following kind of information and present it to your surpervisor:

  • Number of bugs that slipped through in the past 6 months
  • Total / Average Time (and cost) spent fixing those bugs that slipped through
  • Average Time (and cost) spent fixing bugs when you find them before release
  • Estimated cost if a separate tester was hired
  • Estimated savings (schedule time and $) if those bugs had been caught during test
  • New features that have not been completed due to time spent fixing those bugs

The first three of those will likely be a bit more straightforward for you to capture the information for than the latter ones. But those last two are what will really help make your case.

2. Requirements / Shared Understanding

Have any of the bugs in the past 6 months been due to a disconnect between what Client X wanted and what you implemented? If so, consider going through an exercise similar to the above (replacing testing with requirements capture). Make sure Client X understands how what you are asking for directly relates to them getting a better quality product in a shorter time frame.

Have you gotten any requests for changes / additions in the last 6 months that have caused you to go back and make large changes to existing code that you had recently touched for other changes / additions? Being able to capture this and put a $ value against it can help make the case for them talking with you about their full goals rather than piecing out individual changes at a time. And if you have better understanding of their end goals, you can better advise them about whether certain features are connected and should be undertaken together.

Consider looking for alternatives to formal Functional Specifications to capture requirements in. Look into options like using user stories that allow Client X to convey what they want in language that may be more comfortable to them.

3. Overall Project Management

It sounds like you should have a frank talk with your supervisor. If your "team" is supposed to be handling the management of the project (because that is the expectation of Client X), then it needs to be clear who is supposed to be filling that role. Is it supposed to be you? Then your schedule and deadlines need to reflect that the role takes a certain amount of time to be done correctly, even on a small project.

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.