Managing Java projects – A Contradiction?

4

We as project managers really loved managing projects using ‘conventional’ Oracle tools. Most of us actually started as software engineers in projects using these tools. We had experience, knew all the pitfalls and managed productive software development streets. Things our programmers developed were reusable and were repeated time after time. Estimating a project based on functional specs was a piece of cake. Account managers rightfully put their trust in us and our customers were never (well, almost never) disappointed ....

But then, about 9 or so years ago, things started to change. Our save world fell apart as new tools and programming languages emerged. Java was the word. At first things still looked fine. We too are enthusiastic about incorporating new technologies in the products our teams build to make one more smiling customer. Extra investments needed to learn the new tricks were happily justified. But things started to turn nastier when, after a couple of projects, our delivery managers started to breath down our necks and customers and account managers began asking questions on why seemingly easy things took that long and so much sweat and money to accomplish. Why didn’t the investments pay out?

We of all people asked these questions to ourselves as well. Shouldn’t it be possible to create nice things in a swift and productive way; just as we did in the good old days? Where did we lose perfect control on progress and budget? The puzzle isn’t that difficult to solve although several aspects play their part.

First of all the progress in the Java Internet world was faster than our projects could cope with. This meant that time and again we were working with new components and tool stacks. Investments we did in building experience and knowledge of our team members only partly paid off in the next project. We were a bit too eager to use the newest versions, meaning that sometimes projects got slowed down by immature products. Not being able to enlarge our project management experience based on a stable development environment added to this quotation as well.

Of course the answer to the question posed in the title is ‘No’. Everybody just needs to take a step back and take in the lessons learnt. Project management definitely should take the responsibility, switch off their auto-pilots and stop with just nagging about developers not getting their jobs done as hoped for. They should not allow high risk non-proven technology in projects unless these are specifically branded and planned as ‘Research and Development’. Higher complexity in different components means that old fashioned module based task division doesn’t work anymore. Splitting tasks within a team must be technology based. Non-functional technical components form an essential part of the total effort.

Real project success however needs a different mindset from all involved. Customers must know what they ask for and should be helped by account managers and business consultants who will tell them what to ask for. Creative minds must never be hindered, but we all need the realistic view of the technical masterminds on whether technologies are mature enough to contribute to quality and productivity in ‘dull’ real world projects.

On the technology side, from a project managers point of view, the sun also starts to break through the clouds. At last the dust seems to settle. Mature products like ADF and JHeadstart really boost our productivity in creating Java based solutions for our customers. It almost sounds as the start of a happy end. To be continued?

Share.

About Author

4 Comments

  1. Ronald Toonen on

    Nice story Rob!
    Maybe this is not only a Java thing. I remember the first Headstart (including CDM-Ruleframe) project after years of experience with designer and forms. We faced similar things as you describe, we also learned a lot……
    So in general what can we do as project manager to stay in control when unpredictable tools/techniques are used? As you mentioned the risks grow, but I think the project team changes as well and needs more attention.

  2. Exactly my point Andrej; at least one of my points. We can’t stop anybody from dreaming about productivity figures that compete with forms/designer projects. But of course it shouldn’t, as you so rightfully put it, be the only argument in the discussion on whether or not to use certain tools and technologies. That’s why I plea for a different mindset of all involved including account managers, business consultants and the customers. What I don’t want to forget either is that current productivity in Java projects should and could increase. So let’s not compare Java projects with forms/designer projects, but Java projects how they are and how they should be.

  3. What bothers me is these forms/designer people always comparing productivity of java with the productivity of forms/designer.

    It doesn’t really matter if the productivity of java is lower than of forms/designer.

    What matters is that your investment is rewarded by a bigger return on investment.

    For example: if you’d created amazon.com using forms/designer you would have been finished earlier than when implementing it using java. However, i bet you would have sold a lot less books using webforms amazon.com than using html/java amazon.com.

    Ergo: higher productivity can lead to less income. It’s all about investment and return on investment. Absolute productivity doesn’t really matter.