Seven IBM i project lessons learned in 2008

Jim Mason, Contributor
12.19.2008

Jim Mason What is a lesson learned? Is it something that went well for you or someone else that you want to emulate? Is it something that didn't go well that should be avoided in the future? When I look back on the successes and failures I've seen in 2008, the biggest issues weren't technical ones – they involved managing people, tasks and expectations. While choosing RPG over Java for an application may have good or bad effects, the more important issues concerned decisions, processes, communications, expectations, planning, resourcing and management of tasks and people. Here, I'll focus on seven key lessons I learned this year that can make a difference in your job, your team's success and maybe your company's success. Working hard or working smart? I finished a project that was delivered on time but a little over budget. After half the team spent six months working long hours consistently on nights and weekends, it was disturbing to sit with the CIO and have him say we didn't do a good job because we consumed more resources than planned. His management team knew we had put in long hours. His point to me: were you working hard or working smart? We were working hard. Did we work smart? In his view: no. There should have been a better way to get everything done with less effort. It was clear the management team had assumptions about what was possible. On this project, most of the key decisions on resources, assignments, process, software, tools, scheduling and so on were dictated to the project team by the management team. The project team had lots of responsibilities and very little decision-making authority. Thinking about how to change that, I realized we didn't work as smart as we should have. We pointed out all the problems up front with key decisions and constraints we were given by the management team. We were consistently ignored, and told these were constraints. In hindsight, I should have worked smarter by focusing on the next point – manage your manager. Manage your manager It's not enough to manage your team and your work, you need to actively manage your manager. You need on-going communication to ensure he is maximizing his efforts to support the success of your project. In theory a manager's job is to provide the directions, resources and support you need to be successful. But, in many cases a manager may have neither the time, details or understanding of affects of decisions on a project's success. It's your job to manage your manager to ensure he is aware of all the key issues and affects of decisions on the outcome. It's not enough to manage your team and your work, you need to actively manage your manager. In our case, we did clearly bring the issues to the table during the project at key points. When we didn't always get the support or decisions we needed, we went back to work. As a team, when bad decisions were made, we needed to do a better job of measuring their affect and formally pushing that back to management to make changes to the project. In hindsight we didn't do enough to manage our management team effectively. Socialize your success If your project reports directly through one manager, clear and timely communications can be easy to achieve. On my last project, there was a large team of senior managers managing the resources and personnel the project was dependent on. Those senior managers controlled many of the decisions affecting our project. When the CIO looked for feedback for improvements, the senior team gave him input that collectively was passed to us. It was apparent from the comments that while problems and challenges had been identified (that the team fought with hard work), the PMO and other managers did not always understand the root causes, nor did they see all the successes our team achieved. In hind-sight, not only did we need to more formally push root causes back to a wider audience in a politically acceptable manner, we also had to correctly socialize our successes to this wider audience on a very regular basis. Instead the wider team would hear of an issue, but not the resolution. Our team (PM, etc.) needed to be more proactive in getting good feedback from the outside audience. We did the standard items: weekly project meetings with published notes, daily development scrums to manage priorities for the day, a project wiki tracking all the open issues and priorities. Those items were used by the team but the wider audience didn't pay them much attention. On future projects, we'll need to be more proactive in socializing the good work accomplished as well as highlighting changes that are needed. Protect the data, protect your job People who understand the business data, analyze data quality, manage it and support processing data directly are the most indispensable resources in a company It's a tough economy and getting tougher. Looking at the last company we delivered a large project for, the staff who were best positioned to do well and survive any IT layoffs were the ones who "protect the data." People who understood the business data, analyzed data quality, managed it and supported processing data directly (feeds, batch etc) are the most indispensable resources in the company. While delivering new solutions and maintenance requires other skills (e.g., systems support, networking support, development skills), those individuals who have ownership on the IT side for business data are the most critical resources at any company. Outsourcing and contractors can be used as needed to cover other areas. Quality comes first Not second. My last large data warehousing and reporting project had some bad assumptions up front about the data. When I asked if we would add logic to define data test conditions and data edit rules, I was told that, no, we didn't need to do that. These were existing internal or external data sources that were already being used, and they were trusted, so we wouldn't do that work. Lesson learned: always define the data test cases (not just the data) up front and validate it. Our project proved that trying to rework systems that are already built to fit data conditions discovered after the fact is 10 times more expensive. This was a bad decision that cost more than anything else. Quality data analysis and automated data test cases can make the biggest difference on many projects. We had the right tools to make automated data regression tests easy but were told it wasn't part of our plan. In general, a test-driven development process that focuses on developing executable test cases up front to support requirements and application use cases and then run them continuously as automated regressions will produce higher-quality solutions with less work. Cost reduction is more important If your IT department doesn't need to focus on this as a top priority going forward, you're lucky. IT costs are even more of an issue in a tough economy for most companies. So you want to ensure IT's budget cuts are limited? Then focus on adding value in IT by cutting business operations costs more. How do you do that? Ask the business users where they spend their time. If users aren't giving clear answers on where to cut operations costs, then look at Microsoft Office. Microsoft Office – email, Excel, Access, Word, Powerpoint equals time lost in many companies -- lot's of it! It's true that we couldn't live without those emails, documents and spread sheets -- but they don't necessarily need to be in the Microsoft format. One company analyzed their application portfolio. They found 60+ IT supported applications and 2000+ Excel applications managed by users! They took one Excel application that cost 15 days to produce with VBA etc. It was re-engineered as a central database application using open-source generation in four days! After that, the IT department decided there was a large potential cost savings as well as control and data quality improvements in moving many Excel applications into standardized database applications that can be quickly generated. Enterprise open source solutions dominate Commercial software is not dead by any means, but growth is slower, especially in this economy. Enterprise open source (EOS) software solutions have picked up critical mass now in many businesses. Beyond saving up-front licensing costs (in the case of some vendors, that's hundreds of thousands of dollars), it turns out EOS also often has lower support and implementation costs. Commercial solutions that are working are not usually worth replacing. On the other hand, if you're buying an application, infrastructure or tools, you should look to see what EOS options are out there. My team has had great success using a variety of EOS solutions where commercial software has been used normally in System i shops. So who produces EOS solutions? Commercial software vendors (IBM, Sun, Oracle and more) as well as individuals and organizations like Eclipse and Apache. For example, IBM has WebSphere (a commercial Web application server) as well as WebSphere Community Edition, a free, open-source Web application server. IBM provides support plans for both. That's my short list of key lessons learned from 2008. Your lessons learned will be driven by your experiences. Hopefully you'll pick up something useful for next year from mine. My next column on best bets for 2009 will focus on key technologies with big potential payoffs for System i shops. ABOUT THE AUTHOR: Jim Mason has worked with ebt-now as a System i Web consultant delivering architecture, development, training (QuickWeb workshops) and support for IBM WebSphere software and enterprise open source solutions. Jim has participated in IBM beta programs for System i software. He writes articles and teaches on System i Web technologies. He also speaks at a variety of System i conferences. You can reach Jim at jemason@ebt-now.com.