By Juha Mattila, Col (ret), studying in Aalto University, Finland 7.3.2014
Contents
- Description of situation in the beginning- Situation in Application development department
- Three possible courses of action was defined to overcome above mentioned challenges
1. Isolate application developers from clients, apply more control but simultaneously
increase agility to be able to answer client’s requirements
2. Let situation be as it is but gradually build better readiness to do firefighting3. To utilize strict line organization with more midlevel managers and specialized developers
- Summary
Description of situation in the beginning
In 1997 I was one member of the management team for newly assembled Centre of Information and Communications Technology of Finnish Defence Forces (CIS Centre of FinDef). It was the first time when FinDef tried to integrate telecommunications with information technology and to create common architecture with centralized development. There were four main departments in the 1997 started ICT-Centre: R&D, Applications, Infrastructure and Network Operations Centre. These departments were supported by small administrative unit of HR, Procurement, Security and Supplies functions. This paper is based on my subjective perceptions of that time and events as one department head. Thus this paper is not a study but might be used as a source of examples.It was the time when FinDef Intranets were updated to IP-technology, Data connections reached n x 2 Mbps throughput, all garrisons were provided with Local Area Network, Applications were implemented each in their own server and different security domains were isolated with Virtual Private Network connections and physically separate servers, LAN connections and workstations. Almost all administrative departments/functions in FinDEf were either developing or using their own IT-systems like VAX/VMS/Oracle based application for material registry, MS SQL based application for enlisted HR, VAX/VMS/Oracle based application for reservist HR, UNIX/Oracle based application for C2 and NT/Lotus Notes based application for office automation. Additionally Centre was able to support VAX/VMS based subscriber database system for PABX-system, maintained two major PABX-systems (LME MD and ISDX) and vast network of PDH and SDH technology using both cables and microwave links. All this was managed from one network operation centre that controlled several CIS -units in provinces.
The original management group of CIS-Centre was trying to integrate the development and maintenance of Information and Communications Technology as much as possible, save man hours and introduce first centralized services to all users in Defence Forces. Before establishing the Centre management spend many hours in workshops trying to define main processes for centre to improve its productivity. It was recognized that one of the many problems was legacy attitude for client relations. Application development teams were functioning in isolated pipes with good relation with clients, but with no cooperation over team boundaries. This culture lost all synergy possibilities of utilizing same technology albeit in separate servers. Communications developers had more like command relationship to operator organizations in each military province. All development came from top to bottom and no-one was listening user needs nor their opinions of malfunctioning telephone services. Network operation centre was using very primitive Telecommunications Management Network -based processes but they were not extended to province centres, which were doing all configuration management.
Situation in Application development department
1. Functionally structured department
Application development department was a unit of about 50 experts in application development. They were structured in teams that were very close to process owning department like HR, Materiel, Finance, Readiness, Operations, etc. Together 8-10 teams were dedicated each to development of their process domain. It was almost impossible to rotate experts from one team to another when major implementation phase was done. Starting of a new project required always recruiting. At same time there was a trend, in which every department in Defence was trying to improve their functions by developing at least one information system of their own. This tendency was threatening to multiply the number of developers without clear business case or the return of investment calculations for each application initiative. Every system was developed around individual datamodel, so there was no way to automate datatransfer between systems cost-efficiently. End users were frustrated to retype simple information via each different interface and gradually databases were suppressed by many human based errors. Organization is depicted in following figure 1.
Figure 1: Status of organization in the beginning
Since most of work was done in projects, vendors were also utilized in stove pipe way. Cohesion of each project was good, but process owners were paying similar functions multiple times to same vendor. Information exchange between projects was rare and sometime even denied because of fabricated “confidentiality”. Vendors were more than eager to enforce this kind of ignorance within client organization, but were first to share information at key client relations management level.
2. No architecture or any other framework to guide development
Clients were developing their functions and processes without any framework that could have integrated either processes, functions or their supportive applications. Ideas poured and projects were started almost continuously. New tasks were mixed with existing tasks and often prioritized ahead. One implementation led often further development so small initiative might become a major program. In-house programming was gradually substituted by outsourced programming or tailored commercial of the shelf applications.
3. Increased interrelated complexity and pace of changes within lifecycle created additional problems
Getting everything together for needs of 120 garrisons became harder each day, when more elements was introduced within same structure. When changes were introduced, the whole structure was in brink to come apart. Operating system update required always testing and usually either porting or reprogramming of the applications. Development of GUI and presenting new information required changes in database and datamodel. Changed components were integrated directly in operation without any order or serious system pretesting. This produced a lot of re-engineering, root cause analysis and reprogramming.
4. No information sharing across team boundaries
Teams did not know what others were doing. There was no possibilities to learn from others since people socialized only within their domain. Working culture was competitive and team leaders urged their team members for better achievements compared to other teams. Problems reoccurred and feeling of unjust was easily expressed. Some individuals were irreplaceable for specific clients. One programmer did code the whole application and without proper documentation had an opportunity to “blackmail” both client and department head.
5. No unit spirit or identity as a Centre
R&D department tried to produce standards and “best practices” for development and programming but either people were too busy to really adapt them or were too “experts” to utilize anything but their own procedures. Process workshops presented hundreds of specific processes that were almost individual in nature. There was no unanimity over main processes since every team was praising their speciality and superiority over other teams. Overall the centre was a collection of very different and geographically isolated units, that had no feeling of creating anything together.
Three possible courses of action was defined to overcome above mentioned challenges
1. Isolate application developers from clients, apply more control but simultaneously increase agility to be able to answer client’s requirements
Basic concept was to put some distance in client-provider relation, increase common testing and prototyping, centralize vendor management and shorten the duration of delivery tasks. Main changes are presented in next figure 2.
Figure 2: Productivity by isolation and agility
1A. Build isolation between client and developer team without losing good relations
First challenge was how to loosen the relationship between IT-development project and process owner without creating too much friction to otherwise warm relations. A role of process/domain analyst was created to provide process owner more services and holistic information of possible solutions than single team was able to do. Since dedicated team was also restricted to few systems and few technical solutions, process owners soon noticed how much better service they were getting from more experienced and initiative analysts.
Analysts introduced other developer teams and their products to client, which in the end served better client, but also shared work over developer team boundaries. Both productivity and effectivity of IT-development department improved with this change.
The change required that best people was appointed to analyst roles and they were involved in all solution and technology improvement processes. Also their understanding of processes was improved with training and visits to client’s exercises and facilities. In the end it came down to personal relationship between client representative, analyst and leader of legacy team. If there was misunderstanding, power struggle or otherwise wrong attitude, the relationship was neither productive nor effective. In order to settle these wrinkles, department head had bi-annual client meetings, where all issues were tackled.
1B. Add control but utilize shorted iterative periods to deliver
Second challenge of long projects and inflexibility was resolved by introducing shorter periods to produce a required service. Annual projects were gradually divided into smaller windows: half a year – quarterly – monthly. This enabled department to utilize resources more flexible, because development teams were able to execute other tasks while their primary client was busy elsewhere. Some idle team members were also “rented” temporarily to other teams that had periodical pressures. This enhanced load balancing and in longer term helped to lower some boundaries between legacy teams.
Prototyping and modelling was also introduced in application development to improve understanding of requirements in one hand and to produce possible solutions on other hand. This procedure created the first iterative approaches that were well received by clients especially in user interface development.
Some teams were unable to adapt to shorter “sprints” and they went behind their process owner to get support to their special and untouchable status. This was mitigated by long discussions with client and increasing transparency of team’s work.
1C. Intensify shared testing, prototyping and integration
Since infrastructure and middleware development was outsourced to another department, there was a big change in testing and integration procedures. Infrastructure department provided an updated platform with connectivity, operating systems, database applications and necessary middleware like session encryption. Today this is called platform as a service (PaaS), but in those days it was just rationalizing technical maintenance and development by dividing responsibility where it was reasonable. Infrastructure department hosted laboratories where application department went to execute integration tests and functional tests. Late 1990’s interdependence started to affect in IC-technology and gradually system of system testing was mandatory to sustain availability of integrated ICT-systems.
Sometimes vendors were invited to demonstrate their new technology and solutions side by side with existing technology, so experts were able to capture direct information on new developments. Later this was extended to wider demonstration exercises with multiple vendors on site same time.
Infrastructure department was forced to establish fixed delivery timings for changes in operational systems, which introduced natural change and release management. This was good also to application development teams since they had series of change windows to integrate, to get approved and to have released their new versions.
Some application teams were unable to utilize common platform. They were saying that their system is too tailored to run over standard and security hardened platform or that their system is so confidential that no one else should have any information of their configuration. All this was mainly signs of misunderstanding or unwillingness to adapt new procedures. Some unprofessionalism and quality failures also surfaced during these testing sessions.
1D. Have common control over vendor utilization
A separate acquisition department was created to take care of all procurements and purchases. Fortunately this department included also best overall understanding of markets and different services vendors were providing. This enabled close cooperation between development department and acquisition department without normal friction caused by power struggle, unclear process or different language.
Procurement process was improved both in speed and quality. Individual licences were bundled together and new enterprise license agreements were negotiated. Mass products like desktop applications were standardised, all units under ministry of defence was taken under the same license agreement, which brought both agility in application usage and savings in total costs of desktop applications.
Some teams were too close with their “royal” provider to be able to utilize improved vendor management. They were saying that only current vendor was able to provide their “special” needs. This is normal to human societies as social relations are sometimes stronger than logical realism.
1E. Stick change with new measures
There is always human behaviour behind all processes and procedures. A manager with strong will and authority may be able to sustain new processes but if they are not adapted as every day behaviour, old habits will return when authority vanishes. New behaviour has to be rewarded and old behaviour has to be sanctioned in visible ways or else old habits will emerge again.
Annual service contracts between development department and process owners was introduced to give both short and long term goals to everyday work. Annual team member award was given to experts that had been both socially and professionally productive members of their basic team but also in supporting other teams.
Best way to stick change is to utilize continuous improvement measures (LEAN management), where both individual, team and unit situation is displayed to all stake holders. This transparent measurement should not be used only to drive throughput, but more to drive initiatives to improve processes and methods of work.
After transformational leader was rotated to another positions some of the teams returned to their old habits, because no one was requiring any more new procedures. A mere transactional manager is not enough to stick changes if they have not been adapted as part of normal behaviour.
2. Let situation be as it is but gradually build better readiness to do firefighting
This course of action is not after major changes but rather supporting continuous development and evolutionary approach to allow people, organizations and processes to gradually improve their productivity. This approach may be utilized when people and culture of organization are not ripe for major changes. The structure of this kind of organization is depicted in following figure 3.
Figure 3: Productivity by enabling gradual improvement
If there is no way to prevent adhoc tasks coming from process owners directly to developers, one might be able to improve teams “fire fighting” capabilities. On the other hand major projects should be also executed, so agility is needed to get both adhoc and long term tasks done. Sometimes organization culture is unable to change because of deep habits of functional silos or earlier attempts of change have created spirit of failure and fear. These situations needs very small steps, that people do not see them fearful or unsecure and series of visible quick wins to build courage for advance.
2A. Backoffice support to gain from centre of excellence effects
If teams are too deep in their “fox holes” to change, it might be possible to create small backoffice team of several experts to support others. This backoffice team may be only a pool of high skilled resources that are employed to support other teams when load is overbearing. Better situation would be that backoffice is a real team, that can outperform the legacy teams and show to individual workers an example of new behaviour. Recognized teamwork may tempt frustrated but good workers to join and gradually culture starts to change. If backoffice workers are best experts, they will also gradually start cooperation over team boundaries by spreading ideas with peer-to-peer relations. Some legacy team leaders may recognize from this, that with sharing and cooperating they gain better results. Some legacy leaders will perceive this hostile action and initiate some countermeasures to sustain their power.
2B. Add cooperation by utilizing infrastructure department and their integration environment
Bringing experts together to solve their shared problems also enables transformation of siloed culture. In this case infrastructure department build and maintained laboratories for full ICT-structure and all application were forced to be tested before delivery to operation. In controlled testing environment teams were forced to co-work with infrastructure teams and gradually with their “competitive” application development teams. If testing was not controlled, there was possibility to create more confusion and frustration than productive cooperation. This required expertize from line managers and maturity from their development change management process.
Keeping development team responsible through the whole fielding time of their products integration and quality, helped teams and their members to understand their liability and learn to improve their programming and testing processes.
2C. To enable agile teaming with added situational awareness by task boards and change metrics for rewarding people
To tackle the lack of awareness, a task board was introduced. This tasks board was structured to present ongoing development tasks and their status. Teams were responsible, in Kanban style, to update board and task proceedings each day. In the end of each week team heads and department management gathered around boards to review situation. These sessions included minimizing Work-In-Process (WIP) by allocating backoffice resources and by redirecting tasks over domain barriers. Gradually this increased awareness within the whole department, introduced skilled people over team boundaries and created more spirit as a development unit.
Within teams this enabled change of responsibility from individuals to teams, when all members saw situation and workload. There was no need to ask or require help, since everyone available saw who is needing help at time. Human Resources key performance indicator were also changed to focus more on team outcome than individual results. When helping others improved everyone’s performance appraisal, team work seemed more fruitful even to most competitive programmers.
3. To utilize strict line organization with more midlevel managers and specialized developers
This course of action is relying on traditional line organization with functional units and authoritative managers. It will create control when situation is almost chaos like. It will also add administrative marginal and kill some initiative and responsibility at expert level. The structure of this organization is depicted in following figure 4.
Figure 4: Productivity by control, functional centralization and management
More authoritative approach is working in situations where people have lost trust to others, culture of the workplace is more like “kill or be killed” or personal approach is more like “I am great, but others are not”. In military environment especially this line organization approach is in very core of the culture and adapted behaviour. Biggest challenge is to choose leaders that really know what teams are doing and possess also some social intelligence to cope with different people. This is especially difficult in expert organization. For people this is the easiest and comfortable structure since they are not responsible but their own behaviour. Superior takes responsibility of tasks, processes, quality and outcome.
3A. All tasks are controlled via line managers, no individual is allowed to receive tasks directly
Line managers took all responsibilities to communicate both with clients, vendors and other units. All tasks were given by managers and control was strict for both individual behaviour and contribution. This did stabilize situation and improved productivity of simple tasks. The negative side is that it also made individuals more passive and unable to execute complex tasks in adhoc situations without constant control by manager. So team silos were taken down but the spirit for teamwork was also lost. Some of the previous team leaders resigned because of lost status and authority. Experience and client relations was lost with them. Most negative situation was created if client hired former team leaders as their consultants since ex-leaders had either very negative approach to former department or had intentions to regain their team lead status as the project lead assigned by client. When handpicked initial line managers are being rotated, whole unit might fall into non-productive phase since drive was based on leaders personality and expertize.
3B. Everyone is reporting by hours, tasks and outcomes to management system
To improve managers control over tasks and individual contribution, a reporting systems was introduced where each worker noted their tasks, hours spent and output delivered. This enabled managers to get quantitative information and give both positive and negative feedback. Workers felt that this reporting was violating their earlier freedom and increasing unnecessary administration. A scoreboard of executed tasks was introduced to give direct feedback and enable social pressure. This improved competition amongst some workers, increased stress to some workers and was utilized untruthful way by some workers. Scoreboard did not have same effect as Kanban board nor was it a best base for Lean development but it initiated a controlled change of behaviour.
3C. With more specialized developers their throughput is increased thus productivity increased
Within bigger units some experts gained peer appreciation by executing more tasks with better quality. When managers were both recognizing their improvement and giving them more challenging tasks, their well-being within working society improved and they become new role models for other developers. As original Taylorism has proved, direct feedback to developer increased his productivity and specialization increased throughput. If rewarding was not positive and meeting individual expectations, a hard working developer become stressed, frustrated and was finally seeking other jobs.
Through recognized individuals there was better situation to start building team work than when work society is in chaos and there is no trust between people. Team work beats individual based productivity especially in initiative intensive and agile working conditions.
3D. To utilize lean methods to increase productivity
Managers were trained to divide projects to smaller tasks and introduce them independently to developers. This increased integration problems which was managed by both adding overall integration team and by defining development tasks per singular tread of capability. Shorter task duration introduced new kind of flexibility, since line managers were able to reprioritize more frequently the resource utilization of their unit. It also helped to balance workload more evenly among developers although there was and remained to be different productivity levels within development teams.
Since productivity remains to be both personal, social and expertize issue, a gradual key performance indicator structure was set to drive developers towards initiative and cost-effective solutions rather than continuous patching or reproduction of old code.
Summary
Since there is no one best practice to solve such large variety of challenges, we ended up to utilize all above explained courses of action tailored to each situation, unit and client. This was because teams were at different maturity level, there was no unified working culture and projects were in different phases of development. Neither was transformation planned but rather a series of trial, error and final success steps. Leaders were also different since others were more technical experts than leaders and some more transactional than transformational. With tight cooperation the management team was able to adjust transformation as it was implemented in parallel with balancing essential ongoing development work and building future capabilities.
Later all emerging capability was destroyed by more traditional military management which took over when transformational leaders were rotated to other tasks. They did not feel secure with ongoing transformation but implemented basic line organization supported by staff. They thought that a staff could manage all planning, client relations and vendor management with another feature of Taylorism – central planning. They killed all initiative from developer level and gathered responsibilities from lower level to unprofessional staff level. They withheld all decision at upper level and supressed middle level manager’s initiative and responsibility. In one year’s time the productivity of whole centre was down to half from previous year. Process owners were unsatisfied and starting their own application development projects leaning heavily on vendors capabilities. Garrisons were forced to increase their own IT personnel to fix availability and integration problems. Shareholders were starting to see Centre more as burden in budget rather than value adding organization. All this happened because new management was not educated enough to client – provider – subcontractor value chain management. They did not understand the difference or management between stable functional production and producing one time solutions in to complex systems environment with high expertise team work of both in-house and outhouse resources.
No comments:
Post a Comment