Author: Ant

Kelly Johnsons 14 Rules of Management… for software!

Clarence Kelly Johnson is a famous aircraft designer who worked from the 30s to the 80s on high tech government projects. His management style has become famous because most of his projects ran extremely successful. In fact there are 14 rules of management attributed to him. Here, I attempt to convert them into rules of software management: 1.The software project manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. 2.Strong but small project offices must be provided both by the customer and software development company. 3.The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). 4.A very simple coding and source control system with great flexibility for making changes must be provided. 5.There must be a minimum number of reports required, but important work must be recorded thoroughly. 6.There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don't have the books ninety days late and don't surprise the customer with sudden overruns. (sic I would even go further and do this every second week). 7.The software development company/department/team must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. 8.A good review system (as currently used by…

Read more

Project RMR, you are go!

After 6 months of concepts, estimating, planning, prototyping, designing and hiring, one project is put on the shelf for 6 months, while the other, RMR, has just ramped up to full development. I've spent three weeks setting up the development environment, build scripts, source control, as well as written guide lines for the new project members. I've also spend time implementing some stubs for the services which our client will call, to allow the GUI part of the team to get moving, so they don't wait for us to finish the DB and service implementation. Today the first features were assigned, and very importantly, the integration token was built! Here it is: We're developing using something akin to Feature Driven Development, which is an agile methodology. To enable this, we create branches in our source control and each develop a feature at a time, independently of others in the team. The integration token is used to ensure that only one person merges their branch back into the trunk/head at a time. If you have the token on your desk you can merge. If you don't have it and you do a merge, you run the risk of having to do merges for a whole week as a lesson not to do it again! If your'e wondering what happend to "manager", well it's still being developed, and were actually using it on the project to manage the feature allocation. One nice feature that I built last week is the service locator.…

Read more

Open Plan Noise

I moved into a new open plan office this week, and its still being refurbished. At each entrance, there is a dispenser like this one: I assumed it was there because of the building work noise, but today I saw people wandering around with ear plugs in, even though no workmen were present. It became clear that these are not available due to the refurbishment work, rather due to the fact its an open plan office!  

Read more

manager

manager is the name I have given to my new project management tool. Think Gantt chart. Think Microsoft Project. Then think the real world. Team members have different charge profiles - rates can change during projects. Team members can only provide given effort if they are partially assigned to other projects. Updating plans is largely manual, and tracking of hours spent takes a lot of the project managers time. Once underway, the plan becomes a reality, and things quickly change. The manager is continuously replanning, which is rather an administrative task. He wants to be managing, not administrating. According to Prince 2, a project management methodology, the job of the project manager is to identify and then manage problems. He does so using thresholds. When a given threshold like overall cost, steps over a boundary, he alerts the next level and together they manage the problem, be it with added resources, reduced scope, increased budget, etc. Getting information on when thresholds are over stepped, is again largely a manual and administrative job. In fact project cost analysis is also largely manual, and playing with scenarios, like removal of a feature (a set of related tasks) is largely theoretical, because without the right tools, it cannot take things like team members effort profiles, or holidays into account. Wouldn't it be great if there was a tool that took all this administrative stuff away from the manager, automated it, and just alerted him when there were problems? Well... now there is one.…

Read more

7 Sheets of Requirements

Vision "Replace an enterprise information system that has been developed over the last ten years, to allow it to become stable on a modern architecture, to allow two new business units due to a split in the business to develop along their own paths, and to introduce new features that will take the business into the multinational domain." Inception The business wants to know how much such a system will cost. Although its vital for the entire business to be able to continue, it does make sense to get a grip on the costs of such a system, because with a vision like that, they are likely to explode. So the business has approached the IT department and asked for a conceptual phase to be carried out that includes analysis of requirements, conceptual analysis, migration plans and cost estimates. Great, three months ago we started on the technical side. No requirements at this stage, other than the vision. We managed to put together the architecture though, with big caveats with regards to realisation based on actual requirements. Hang on... shouldn't we have stopped before writing about the architecture and waited for requirements? Well the project manager insisted we keep to the deadlines, so perhaps we could "put something together"? His budget, he can spend it how he likes (I get paid by the hour). Two months ago, we completed the migration document. Again, because of a lack of requirements, it was largely conceptual, with lots of pretty flow charts to…

Read more

SAP, SOA and a GUI

When I first learned about SAP, I was led to believe it was insular. Sharing its data or uploading data to it was possible, but expensive and discouraged. If you have SAP, stick with it. Then came XI, the SAP eXchange Infrastructure which is the SAP offering for Enterprise Application Integration (EAI), or now rather Enterprise Service Bus (ESB). With it, you can build marvellous Service Oriented Architectures (SOA). So what? Well, my experience of XI is that its used as a replacement for IDOCs, BAPI, EDI and the like. Instead of those hard to use protocols, simply subscribe to a published web service. But hang on... If SOA is in use, couldn't we go a step further? SAP isn't very good at really rich clients (GUIs), and chances are, to develop one would cost a huge amount. So what about the idea of building your business logic on top of existing SAP functionality, so that you extend it to suit your business processes, and then build that rich client on top of the SOA that SAP can offer from your business logic? An example would be the project I'm working on at the moment. We need to build a planning tool for use in Service Stations for trains. Service stations consist of a large number of platforms where trains can be serviced. Some types of service can only be done on some platforms (axle change for example). As well as planning which trains go where and when and for…

Read more

DT, EMV and NPR revisited

I'm working on a project to relpace the funtionality of an existing system that is shared by two business units, so that each unit can continue development in differing directions. The customer asked me about how to make the decision of whether to build a change or new feature into the existing system and then later into the new system, or to build it only in the new system and force the business to wait until the next release. It reminded me of the Decision Tree problem I faced before, so I set to work on answering the question. But I ran into a stumbling block. The two solutions are as follows: a) build now in existing system, and then again in the new system b) force the business to wait, and build it later in the new system While the former option might not cost double because of the learning curve of the first implementation, the latter option might take a very long time if the prerequisite features for the change have not already been implemented in the new system. So both options have their own complexities. But in theory we can put costs down, and calculate the answer to the question: a) = 50k + 52.5k = 102.5k (assuming 5% inflation over the year) b) = X + 52.5k = ? Hmmm... how do you put a price on the cost of forcing the business to wait? Well, I struggled with that, because its probably very specific to…

Read more

Imagine you’re spending your own money

As part of the Architecture definition for a project I'm working on, I have been preparing a cost estimate. The idea is that the client wants to know if they need to tender the project out to third parties, or whether it can be developed in house by the shared central IT department, used by several business units. In a meeting with the client today I presented my initial estimates. Me: "So as you can see, the upper cost will be 820 thousand CHF." Business Unit Project Manager: "Hold it there. You do realise there is a cost threshold at 600 thousand right?! Above that, we have to tender the project out, and that will add a delay of two months!" Me: "Sure. In the pre study, there is a project plan showing that an initial estimate places the work at around a million CHF. And in that study, it allows time for the tendering process. But good news, it shouldn't cost as much as a million..." Business Unit Project Manager: "Can't you somehow reduce the costs? You need to bring it down a little more...We are already running late." At this point, my unprofessional answer (which I managed to hold in) was along the lines of "OK. Instead of me wasting my time doing a real estimate, just tell me how much you want it to cost, or rather how much less you want it to cost than your boss already thinks it will, based on the pre study.…

Read more

Gathering Evidence

While working on a previous project, before I had a blog, I remember an incident with a particular boss at a company which thrived on a blame culture. No one cared if software was late or crap. All they cared about was whether another department was to blame. So once we screwed up on a project and his response was "Can't you find an email showing its the customers fault?". In this case, the answer was "No, it was our fault. I screwed up and misread the requirements." Being a good boss, he didn't want to shit on me. "OK, but surely you can find an email that shows its the customers fault? Thats all I need to copy to his boss." He didn't care about the impact on the business. Didn't want me working over time to fix the problem. Didn't want me to accept responsibility for the problem. He just wanted to blame some other department for the problem. And this was the way he worked project after project. Find evidence. Copy the head of the other department. Threaten to escalate... He wasn't alone either. Every department worked in the same way. No one had accountability. It lead to people being scared to make mistakes. Perhaps that was why the company was a market leader? But it wasn't a very nice place to work.

Read more