Managing Java projects – A Contradiction?

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?