Agile Coach, Scrum, Kanban, XP, Lean, Theory of Constraints, Multi-Projectmanagement, Portfoliomanagement

Situation:

• SDV as a service provider is under enormous pressure to innovate because the client banks have high expectations which have been disappointed often in previous projects.
• SDV processes are slow and bureaucratic, especially since compliance rules have been tightened by bank supervision institution BaFin in the aftermath of the global financial crisis since 2008.
• SDV has a reputation of being (too) slow at setting up and finishing projects, regardless of size/scope.
• Projects are planned and executed following a rigid water­fall methodology: without a complete functional specifi­cation from client banks SDV will not create a software concept, without which there will not be any implemen­tation. Then there is a very long test phase at the end of the development cycle. Lead time for transition to opera­tions is several months, ideally pre-planned at the begin­ning of the fiscal year.
• Challenge: more agile processes in a strictly regulated environment without violating any compliance rules.
• Previously started, so-called "Scrum project" is actually far from agile (no client bank involvement as product owners, no public product release after almost 3 years), thus many stakeholders are rather sceptical about applicability of agile methodologies at SDV.
• The next major project on the agenda is OKVS. Its goal is to interconnect existing sales channels per product (checking account, construction loan, private credit) in order to facilitate client-side channel switches during ongoing sales processes, e.g. from smartphone to desktop PC, call centre or local branch bank.
• Furthermore, the currently non-existent channel mobile/ smart­phone has to be created from scratch as a responsive web site which later shall also replace the current desktop/tables process.
• Because overall project duration estimate is 3 years, client banks wish to have earlier releases with important core functionality instead of the usual "big bang" release at the very end of the project.
• Scrum-Master.de is assigned the task to set up an agile project in a way which avoids the bad experience from the previous pseudo-agile project and enables the project team to quickly and regularly deliver and release business value.

Measures:

• The 12 regional banks of the Sparda group delegate all decisions to a steering committee consisting of 3 pilot banks plus SDV and Sparda Consult (SC) instead of having to come to agreements in big management circles of all 12 banks.
• SC sets up a product owner team (PO team) consisting of actual pilot bank personnel and an external Scrum coach in the Chief Product Owner role.
• Scrum-Master.de sets up a cross-functional Scrum team at SDV, consisting of above mentioned PO team, in- and external software developers and other staff from SC and SDV. The Scrum team closely collaborates on site in one big team room. This is the first Sparda project ever featuring direct bank + service provider collaboration.
• Scrum training and ongoing full-time coaching for all project team members.
• SDV delegates recruiting of external developers to me because I seem to "have a knack" for finding the right people even though (or maybe because) I am picky.
• In addition to my roles as a Scrum coach and SDV + SC management consultant I also take operational responsibility as a Scrum Master.
• Introduction of agile development practices: high degree of test automation up to automated acceptance tests, pair programming, continuous integration, feature branch workflow, WIP (work in progress) limit according to Kanban framework in order to avoid harmful multitasking.
• Introduction of modern tools: Spock & Geb for test automation instead of JUnit & Selenium, Git for source code versioning instead of Subversion (SVN), Jenkins with continuous builds for each commit instead of nightly builds only, Maven instead of Ant for build & dependency manage­ment, IntelliJ IDEA instead of Eclipse, Jira Agile with simplified, non-SDV standard workflow adjusted to agile/lean methodologies.
• Abstinence from up-front functional and technical specification, replaced by agile requirements engineering with user stories, directly created by bank personnel in the PO team. The PO team directly discusses stories with the development team, utilising short feedback loops.
• Introduction of in-sprint acceptance tests per user story by PO team
• Establishment of two-week Scrum sprints with mandatory delivery of tested and accepted product release by the end of each sprint.
• Fight for more development team autonomy with regard to technological decisions, resulting in forward-looking, trend-setting decisions for non-SDV standard architectural and infrastructural approaches and products, e.g. application server, source code management system and many more.

Results:

• Quicker decisions due to steering committee model. Scrum enables decision makers to learn along the way and refine or adjust the project plan accordingly, e.g. by adding an innovative, previously unplanned feature to the backlog of which nobody knew at the beginning of the project if and how it could be implemented conforming to the law.
• Shortened release cycle: first release (public launch of OKVS platform) after 6 months, second release 3 months later, third release 6 weeks later.
• Due to ongoing in-sprint PO tests shortened acceptance test phases from min. 7 down to max. 3 weeks because of continuously tested product quality and test coverage.
• For SDV projects unprecedentedly high degree of test automation
• By the end of 2015 SDV carries forward savings of 1M € of the project's development budget (2.8M €) to 2016 due to efficiency increase based on agile methodology.
• In addition to the initially planned 7 Sparda regional banks the remaining 5 also decide to use and co-finance OKVS after the successful launch after just 6 months. Usually it is rather rare that all 12 banks are on board.
• Strategic decision by both Sparda banks and SDV to henceforth prefer Scrum for big, complex projects incl. cross-functional teams with direct bank participation.
• Strengthened mutual trust between clients (banks) and service provider (SDV) due to daily and direct collaboration in OKVS Scrum team. Previous compart­men­talisation is reduced significantly, there is an ever increasing culture of mutual trust.
• Several technologies introduced by OKVS are promoted to SDV company standards.
• Because of the consistent and reliable 2-week Scrum release cycle there is a growing desire by the client banks to put releases into production more often. First steps towards a DevOps model (close collaboration between development and operations) are taken. For instance, production deployments now only take minutes and a few button clicks. In previous projects releases were still burned onto CDs and physically transported across departments together with a (paper) release process slip, requiring many signatures. At the end of the process, releases were installed manually, usually causing significant downtimes.

Situation:

• Small internet agency, entrusted with biggest project in company history
• Quick growth of personnel due to recruitment of develop­ment specialists necessary to scale this very project
• Because of previous chaotic projects the CEO and the client want to do "better planning", resulting in a rigid waterfall approach with detailed up-front planning and design.
• Project has been ongoing for one year, but not even the visual design has been finalised and delivered by an ex­ternal agency because everyone got lost in too much detail.
• Two months until strict deadline (main season for booking winter trips is in early summer)
• Belated launch = insolvency for Tegtmeier because of project assignment revocation without payment (work and labour contract, not time and material)
• Stress, nervous team atmosphere
• No more belief in project success
• Company founder, owner and CEO has no more trust in his own team, thus rigidly micro-manages everyone and thinks that without him nobody does anything right.
• Personal conflict between CEO and big-headed, know-it-all, insubordinate lead developer

Measures:

• Review of all relevant aspects: catalogue of requirements, methodological approach, interpersonal conflicts, vastly different levels of competence within the development team
• Scrum training for CEO and team
• Personal coaching for CEO in order to reduce his suffocating micro-management and free him for more important tasks
• Coaching for a hand-picked, integrative personality (organisational psychologist) into the Scrum Master role
• Team building: forging a team from a heterogeneous group of individualists, including the "diva" lead developer
• Coaching the client CEO into the product owner role with an emphasis on agile requirements engineering
• Collective creation and refinement of a strictly prioritised product backlog
• New "cut" of previously bulky and very technical requirements as small, valuable, end-to-end user stories, focusing on essential business value needed for launch (minimal marketable product)
• Open discussion about conflicts in retrospectives
• Creation of new mutual trust between Scrum team and their own CEO on one hand, between service provider and client on the other hand.

Results:

• New confidence within the Scrum team into their own ability to deliver the product on time.
• Product owner says he feels "liberated and empowered", because now he has learned the craft of cutting and priori­tising user stories. In the past he always thought that every­thing had to be specified and delivered in one big chunk in order to be valuable.
• Social balance within team is re-established, atmosphere gets more relaxed and motivating
• First sprint is very hard, difficult and controversial for everyone, but at the end the team delivers a functional product increment against everyone's expectations. This leads to grooving trust and confidence within the team as well as by a very impressed and surprised client ("wow, they can actually deliver").
• Second sprint goes much more smoothly, the group transitions into a real team.
• Despite deadline pressure and CEO's preconceptions against test automation ("I like to have it, but it costs us too much precious time.") the Scrum team invests a significant amount of sprint time in test automation. Quality increases, regressions (an old problem) diminish and are identified much earlier.
• Release deadline is met successfully; CU Ski goes online in July 2015 as planned. Multiple releases follow in short cycles according to the Scrum framework.
• Simultaneously the existing portal CU Camper (camping & motor home travel) gets renovated and refactored to the new, technologically superior CU Ski design.
• Tegtmeier eK re-stabilises as a company, its legal form gets changed to GmbH (similar to PLC).

Situation:

• Scrum was established as process framework three years ago. Management is satisfied because Scrum has led to measurable improvements. TRUMPF as a mechanical engineering company has an enterprise-wide continuous improvement (kaizen) process in place, i.e. improvements are measured on a regular basis and the bar gets raised annually by declaring new improvement goals.
• The new goals cannot be achieved with the existing processes. Especially release cycles are too long and too expensive.
• Different agile process maturity levels across teams
• External supplier integrations into Scrum process framework is problematic

Measures:

• Review/assess multiple teams during their daily work
• Participate in regular Scrum meetings (Daily Scrum, Sprint Review, Retrospective, Planning, Backlog Grooming)
• One-on-one interviews with Head of Department, team leaders, Product Owners, Scrum Masters and in-/external team members
• Several jour fixes per week with Chief Department Manager, daily meetings with Head of Department for provisional results report and dynamic prioritisation of next steps
• Formulation of status quo description (review/assessment result)
• Formulation of catalogue with measures of improvement

Results:

• The catalogue identifies and describes ca. 50 concrete measures of improvement. By customer request, each measure contains ratings concerning impact and effort/duration of implementation.
• The catalogue encompasses topics such as organisational development, project management, technology, agile development & test practices, selection of and contract design for external suppliers.
• To the client’s surprise – TRUMPF management had assumed that the existing process implementation was quite mature – the identified potentials were not merely marginal but massive. From an assessor’s point of view there was a lot left to be desired concerning professionalism in all areas mentioned above.
• Preliminary discussion of review results and improvement measure catalogue with management
• Result presentation and discussion during a workshop with team leaders and Head of Department
• The client followed the assessor’s advice for maximum transparency and we presented and openly discussed the findings and all improvement measures with the complete department staff. Everybody participated in a prioritisation workshop and the top management used the prioritisation from the employees’ point of view as a (non-binding) basis for final prioritisation.
• Discussion of employee feedback within management and creation of final, prioritised improvement roadmap
• Furthermore TRUMPF tackled the area of external supplier contracting even while the assessor was still in house. Existing suppliers were replaced by others more willing to work on-site, other supplier contracts were modified to also get off-site team members on site for better integration in cross-functional Scrum teams. This measure had not even been on the agenda before the reviewer/assessor identified it as a pain point. In an atmosphere of mutual trust the client followed the assessor’s counsel anyway.

Situation:

• Existing legacy product is powerful, but does not scale well (only via extremely expensive special hardware) and has an old-fashioned, unergonomic user interface
• Existing prototype (proof of concept) for a new, scalable platform with state of the art user interface and real-time analysis capabilities has a high market potential, but inadequate architecture, poor code quality and zero test coverage
• Established internal processes are extremely slow and "waterfall-like" featuring a lack of internal communication between company departments and hostility against innovation ("we have always done it this way")
• Internal resistance and high scepticism against the new platform idea, even though the legacy one has noticeably reached the end of its life cycle and was not sold to new clients in a long time (company lives on service contracts)
• Deadline pressure because one instance of the new, not yet existing platform has already been sold to a customer who was impressed by a prototype showcase. Delivery is due in 6 months.

Measures:

• Management coaching (CEO, board and below)
• Creation of a new project team
• - Selection of internal employees
• - Recruitment of external specialists
• - Selection of team members from a USA-based sibling company and bringing them over to Germany for initial team building (duration: 3 months)
• Interim Scrum Master role during ramp-up phase
• Training and coaching for Product Owner, future Scrum Masters and team members
• Breakup of organisational and infrastructural impediments which previously were regarded as given and unchangeable, against considerable initial resistance
• Introduction of state of the art development and engineering practices like test automation, peer reviews, continuous integration and deployment, code metrics, clean code principles
• Switch build infrastructure from Subversion, Ant to Git, Maven, Jenkins incl. intensive use of feature branch strategy (similar to GitFlow)
• After 3 months the US team members return to their home country. Subsequently Scrum gets changed toward a distributed setup with Scrum of Scrums. Common code base and continuous integration practice are being kept.

Results:

• Virtually unmaintainable prototype is refactored into a modular platform which permits cluster operation on standard, off the shelf hardware and next to linear scalability with regard to performance
• Delivery deadline for first client is kept
• Open and collaboration-friendly communication culture across team and department boundaries is established
• Massive reduction of scepticism by means of rigorous transparency concerning Scrum process and development progress ("information radiators")
• Creation of trust in power, stability and market potential of new application platform
• Official strategic switch with regard to marketing and sales towards new platform; legacy platform is officially declared discontinued in customer communication

Situation:

• Complex, scaled Scrum project with hardware and software sub-projects, many (90%) external team members, external suppliers and distributed teams
• Scrum introduced 9 months earlier
• Problems due to a lack of methodical discipline ("Frankenstein Scrum")
• Project behind release schedule
• Unclean, non-agile release planning
• Lack of transparency
• Teams regularly deliver less then 50% of planned story points
• Harmful multitasking: much work in progress, little work finished and delivered

Measures:

• Management coaching (Head of BU, Technical Lead, Chief Product Owner, Team Product Owners, Head of Program Management) concerning agile multi project management, Theory of Constraints, requirements engineering, user stories
• Introduction of Kanban as an alternative to Scrum for supporting teams outside product development such as DevOps und task forces
• Training & coaching for Scrum and Kanban teams
• Coaching for Scrum Masters and Kanban Senseis
• Inter-team synchronisation via Scrum of Scrums, master product backlog, communities of practice
• Improved management reporting on a daily basis
• Transparent and realistic release planning based on team velocity (not the management's wishful thinking)
• Scrum Master role for "agile showcase" team in order to prove to management and other teams what is possible if Scrum is implemented and practiced in a clean way
• Transfer of successful practices from showcase team to the other teams
• Internal relocations in order to gather developers, testers, product owner, Scrum Master per team in one common office so as to eliminate temporal and communicative overhead
• Migration from existing project management tool (which was a bad fit for Scrum/Kanban) to a full-blown, enterprise-ready agile software tool
• Establishment of state of the art software engineering practices: significantly increased levels of test automation and coverage, continuous integration & deployment, pair programming, introduction of and adherence to a Definition of Done for each team
• Introduction of a clear and strict time-box principle for sprints and meetings

Results:

• Groups become real, self-organising teams with more responsibilities and higher (self-driven) quality standards
• Sprint reviews with more participating stakeholders and a clear focus on live demonstration of potentially shippable software & hardware instead of Powerpoint slides and concept papers
• Abolishment of "mini waterfalls" and long-running stories distributed across multiple sprints by means of better and more agile requirements engineering
• Significantly increased velocity via team stabilisation, less WIP (work in progress), fewer unplanned disruptions by stakeholders during sprints
• Strongly improved delivery reliability: teams deliver what was planned for the sprint, not just half of it
• Scrum Masters attack impediments earlier and more resolutely because sprint backlogs and task boards are better maintained, thus impediments become transparent much earlier
• Stakeholders have better access to information because teams maintain information radiators and cleanly track progress on a daily basis without much overhead
• Realistic release planning based on velocity data and team estimates, not on vague assumptions
• More output due to sustainable pace: "panic mode" and "ad hoc management" are replaced by clean work mode
• Each sprint result gets delivered to stakeholders: fictions get replaced by facts, quality increases

Situation:

• Project has been stuck in planning phase for years because planning always lags behind reality, toll gate "planning finished" is never reached
• Internal processes are too bureaucratic, not agile enough
• Many stakeholders, many project participants, distributed locations
• Fear of starting the actual project work and make some verifiable progress in spite of partly unclear requirements
• Wish and need for ongoing, flexible planning and
  (re-)prioritisation

Measures:

• Management consulting (workshops + one-to-one sessions) concerning Scrum in particular and lean/agile in general
• Action plan for Scrum rollout throughout the project organisation including stakeholders from areas outside IT
• Scrum training for initial project core team + management
• Catalogue of suggestions for improvements in planning, estimation, resource allocation. Main goal: significant reduction of harmful multitasking

Results:

• none (large-scale project ongoing at the time of writing)

Situation:

• Maturity level of project portfolio management is satisfactory for the current (waterfall-like) process model, but a more agile project management approach is desired and the portfolio management board needs a meta process which fits the one to be used in future projects
• Lean production is well established in engineering projects, but not for IT projects which are managed bureaucratically with a classical approach (up-front planning, waterfall phases, Gantt charts, toll gates, long decision-making cycles etc.)

Measures:

• Introductory kick-off workshop for cross-functional group of managers from different divisions and departments
• Scrum and Lean methodology coaching sessions with several teams of leaders, specifically head of project portfolio management

Results:

• TRUMPF decide to use Scrum in single key projects plus a ToC/CCPM-based approach in project portfolio management

Situation:

• Multi-project management problems: too many open projects, too much work in progress, project durations too long, missing overview about resource utilisation/overload, no consequent prioritisation of project portfolio
• Problems in each single project team: everyone works alone (a group is not a team!), knowledge monopolies, deficiencies in planning and coordination
• Problems for individuals (especially experts): work overload, excessive multitasking, regular overtime – yet nothing gets done in time

Measures:

• Implementation of Scrum as a general management framework for teams and project managers
• Iterative-incremental creation of value with concentration on quality, regular delivery, getting things done
• Strict Kanban-style WIP (work in progress) limits
• Introduction/evaluation of process metrics utilising existing project data: load per project/employee, degree of multi­tasking and project slack, project throughput (with regard to turnaround and earned value)
• New rule: people (without regard of rank or expertise) help out others, specifically bottleneck resources. Reason: Slack in areas other than the bottleneck does not do any damage, but better utilisation of the bottleneck increases overall work stream throughput. Side effect: knowledge transfer.

Results:

• Better overview where time is lost
• Understanding that (and why) multitasking is harmful and needs to be reduced to increase throughput
• Groups evolve into real teams
• More knowledge transfer, fewer monopolies
• Higher project throughput (earned value)
• Prioritised project portfolio increases predictability and plannability

Description:

• Scrum introduction at Parallels Automation division, location Moscow (location Novosibirsk with 3rd product line due to be switched to Scrum later)
• On-site training + coaching for several months
• 2 of 3 product lines (ca. 80 employees) in multi-level Scrum of Scrums process (several teams per project)
• Switch from specialised to cross-functional teams
• Collocated Scrum teams: people from two floors moved from cubicles grouped by specialist team to open spaces grouped per cross-functional Scrum team incl. Scrum Master and Product Owner
• Create and moderate Meta Scrum team of managers with its own Meta Backlog and Product Owner (head of division) in order to centrally manage Scrum introduction and other organisational improvement initiatives
• Switch from old (waterfall) planning and reporting tools to Scrum artifacts
• Introduce lean management principles to planning, decision and development processes
• Introduce continuous integration
• More test automation, earlier + more frequent testing

(Intermediate) results:

• 8 teams working with Scrum (Sep. 2009), others planned
• Management team also working with Scrum → fractal self-similarity of macro vs. micro processes in management vs. project teams
• Time-box principle established: no more exceeding iteration time-frames, which was a formerly usual anti-practice. All Scrum sprints finish punctually.
• Self-organising teams instead of tasks assigned by team leaders
• Release planning now according to measured team velocity instead of wishful management thinking

Description:

• Strategic 1&1 project (biggest ongoing project in the web hosting division at this time)
• Project structure & participants:
  • Cross-functional project team consisting of software developers from three different product teams and one core development team, plus team members from user experience, technical product management, editorial office and quality assurance
  • Project manager reports to head of project office, head of web hosting division and CTO
  • Methodology: Scrum (incl. responsibility for initial intro­duction and process adoption)
  • Scope & environment:
  • Total duration approx. 1.5 to 2 years
  • 10 developers on project at an average across phases
  • Main goal: re-implementation of a web site builder for several millions of 1&1 customers, scalable operation on hosting hardware
  • Other goals: introduction of an ESB (enterprise service bus) for intra- and cross-divisional process communi­cation; development of a declarative UI (user interface) description language enabling multi-channel applications from a single UI description (e.g. rich client for broadband customers, thin client for modem/ISDN customers, mobile version for access via cellular smart phones)

Responsibilities as project manager / Scrum Master:

• Lead cross-functional team
• Schedule time and resource plans
• Introduce and steer Scrum process
• Monitor and report progress & cost
• Coach product owner for his client role in the project concerning
  • agile release planning,
  • identification of and prioritisation according to business value,
  • story writing
  • Introduce
  • unit testing,
  • continuous integration,
  • code coverage metrics,
  • project wiki,
  • bug-tracking system

Responsibilities as Scrum evangelist:

• Management consulting concerning Agile Enterprise (e.g. Scrum in multi-project management)
• Scrum trainer (training classes, workshops) for several project offices across divisions, developer teams, product marketing and product management, editorial office, support, quality assurance and others
• Coach/supervisor for Scrum adoption, primarily within web hosting division, but also in other divisions; support for other projects choosing Scrum as their process model
• Speaker at in- and external academy days & conferences with Agile Enterprise topics like "Scrum @ 1&1 – why multitasking is such a bad idea for individuals, projects and multi-project environments", e.g. (slides in German!) http://www.andrena.de/Entwicklertag/2008/Vortraege/Scrum-1und1.html

Description:

• Open company-wide colloquium (90 min.) with introductory lecture about agility in general and Scrum in particular, organised by EB's head of quality and knowledge management
• Decision by EB to use Scrum as their new method of choice for software development and project manage­ment in an already long-running project, effective 2008/03. Main reasons were the need to react to ever-changing requirements and priorities by EB's customer.
• Scrum-Master.de is mandated to ongoing coaching via e-mail (on demand) and on site (scheduled once per iteration). Counselling during retrospective meetings on site in order to improve the Scrum implementation in a continuous improvement process.

Result:

• External customer, sceptic against Scrum at the beginning, fully accepts EB's approach after three months of proven advancement (better require­ments engineering, better quality, on-site live sprint reviews, frequent releases).
• EB's customer accepts and begins picking up Scrum terminology in spite of the company's deeply rooted waterfall process.
• Customer takes on an active part in product backlog generation and maintenance.
• EB asks Scrum-Master.de to support them for two full months, which I had to decline at the time because of another long-term assignment.

Description:

• Scrum already established, but without guidance of an experienced coach
• Problems with Scrum process implementation
• Goal: better understanding of Scrum values & rules, improve product development process as well as principal vs. agent collaboration

Description:

• Strategic NVG project
• Project structure:
  • Four sub-projects with cross-functional teams
  • Sub-project managers report to general PM
  • General PM reports to management board and steering committee
• Project staff:
  • Two software development departments
  • IT operations
  • Multiple insurance operating departments
  • Three external service companies (electronic archive, software development)
  • Project scope & environment:
  • Transition from paper-based to electronic work­flow for insurance application processing and document routing
  • Fully automated rule-based policy decision & printing for standard cases (new feature with dramatic throughput increase)
  • Interface to new medical expert system for risk assessment
  • Switch from host-based application processing via text screens and cryptic numeric key codes to Enterprise Java system with two full-featured GUI clients - one in Java (Eclipse RCP), the other in C# (.NET) - for different parts of the workflow
  • Interfaces to 20+ CICS-based legacy host systems via MQ Series
  • Two archive back-ends for inbound (FileNet) and outbound (IBM) mail, incl. scanning, indexing, viewing, electronic annotations & highlighting
  • Interfaces to two different workflow routing systems (host und Tibco)
  • Integrate the whole system into NVG's internal security system (authentication, authorisation, roles, access rights)

Responsibilities as general project manager:

• Coordinate sub-project teams
• Interface with internal client stakeholders (business requirements) and project teams (technical implementation)
• Report to management board and steering committee on a regular basis
• Analyse business requirements
• Lead software architects towards application design
• Organise technical training and coaching for project teams (internal developers are host, Cobol, PL/1 specialists with zero Java knowledge)
• Project management (time, scope, resources)
• Lead requirements engineering
• Organise and moderate meetings & user interviews
• Establish project wiki as an open central information platform with maximum visibility/transparency
• Introduce tools & metrics for software development (use cases, UML, CVS, unit testing, code coverage, build management)
• Coordinate internal development teams with three external companies' consultants

Result:

• Successful on-time, on-budget delivery of analysis & design documents plus proof-of-concept prototype
• In contrast to the client's original intention the "learning prototype" was not thrown away, but used productively, because it contained considerably more functionality than planned and provided for a significant amount of business value, as it already connected all target systems with one basic process workflow.
• NVG decides to fund four subsequent project phases within a time horizon of 2 years.

Description:

• COI's core product has been (since 1988) and still is an integrated system for electronic archiving, document management and workflow, targeted at fortune 500 companies.
• The new product line COI-Intelliger is to establish knowledge management as a new strategic product segment.
• Project structure:
  • Five sub-projects
  • Sub-project managers report to technical product manager
  • Product manager reports to CEO
• Staff:
  • 5 internal developers for QA and integration testing
  • Product marketing, sales representatives
  • Development partner in Eastern Europe develops outsourced with 25 scientists, developers and software architects
• Scope & environment:
  • Highly scalable server capable of indexing multi-terabyte sets of documents
  • Automatic classification & clustering, topic maps for huge enterprise data vaults by means of self-learning algorithms (neural nets) and advanced statistical methods
  • Automatic on-demand generation of content summaries/abstracts with user-specified length
  • Automatic structured index extraction for archive/DMS content
  • Automatic full-text extraction from scanned documents via integrated server-side OCR engine
  • Associative similarity search for natural language queries of arbitrary length (words, sentences, paragraphs or whole documents), either via direct user input or drag'n'drop
  • Multiple data sources for centralised knowledge management: file servers, archive/DMS systems, databases, groupware and e-mail data stores, intranet & extranet (via crawlers) incl. user authorisation for restricted data sources
  • State-of-the-art GUI client with integrated multi-format viewer (200+ file formats) can be used stand-alone for local content or as a connected client for content centrally indexed by an enterprise server
  • Web client for portal and intranet integration

Responsibilities as product manager:

• Take over badly running project with massive schedule, quality and communication (open quarrel with development partner) problems as a troubleshooter
• Create & prioritise technical requirements document
• Define feature set for initial and future releases
• Lead developer and test teams (in‑/external)
• Be single point of contact between management & sales on one hand and technical teams on the other hand.
• Invite outsourcing partner's sub-project leaders to Germany for on-site milestone meetings; before that, only their CEO had ever come to Germany for face-to-face talks
• Keep in constant contact to developer teams in Bosnia via telephone, e-mail, instant messaging; business language: English
• Lead test & QA during alpha, beta and pre-release phases; evaluate results and adapt project plan as necessary
• Define and prepare solution scenarios for presales activities, trade shows and partner training
• Find ways to explain technical details (neural nets, self-learning, asociative search, auto-classification, learning documents, n-dimensional vector spaces) to non-technical customers so as to make clear the product's benefits
• Create presentation slides, product brochures and press articles

Result:

• Successful market launch of COI-Intelliger Suite in time and in budget