This paper reports the experiences on people- and project management issues and how they were successfully addressed to produce successive rapid deliveries of a medical healthcare software prototype, the Soarian Financial product vision. The key practices of people and project management are highlighted and concrete examples are provided to indicate how problems could be resolved. Also, an outlook towards further research on people and project management issues are presented in the context of evolutionary rapid development.

1. People and Project Management Issues in Highly Time-Pressured Rapid Prototyping &
Development Projects
Beatrice Hwong, Gilberto Matos, Christopher Nelson, Arnold Rudorfer, Xiping Song
Siemens Corporate Research, Princeton, NJ
{beatrice.hwong, gilberto matos, christopher.nelson, arnold.rudorfer, xiping.song}@siemens.com
Abstract
This paper reports the experiences on people- and project management issues and how they
were successfully addressed to produce successive rapid deliveries of a medical healthcare
software prototype, the Soarian Financial product vision. The key practices of people and project
management are highlighted and concrete examples are provided to indicate how problems could
be resolved. Also, an outlook towards further research on people and project management issues
are presented in the context of evolutionary rapid development.
1. Introduction
Siemens Corporate Research (SCR) is the US research lab providing its operating companies
with technology innovations that strengthen and maintain their competitive edge. SCR is home to
several core technologies in different research domains including Software Engineering (SE) and
the User Interface Design Center (UIDC). Over the past three years, SE and UIDC have
developed advanced software prototypes and product lines for several Siemens businesses.
This paper is about a large rapid prototyping project, the Soarian Financial (SF) product vision,
executed for Siemens Medical Health Services. The background section describes the context in
which the project was carried out and introduces the Siemens Rapid Prototyping process (called
S-RaP). Using S-Rap as a stable framework in a highly dynamic environment, people and project
management issues are be described. All issues will be supplemented by concrete examples,
quantitative and qualitative data as much as possible. Following that, the measures to resolve the
issues are described. Next, the S-RaP key practices used for managing this project are
discussed. Finally, conclusions and an outlook for research directions on this paper are propsed.
2. Background
Many Siemens business divisions face strong competitive pressures to shorten time-to-market of
their product and service development efforts, a need to showcase the vision of new product
features addressing emerging business needs of their customer, or to evaluate novel software
technologies that will be used in products in the medium to long-term future.
One of the business divisions is Siemens Medical Health Services (SHS) a leading provider of
advanced IT systems for the healthcare industry worldwide. One of SHS’s product lines is the
Soarian Enterprise suite. Soarian supports clinical (SC) and administrative/ financial (SF) hospital
workflows. SF is all about streamlining financial and administrative processes and obtaining real-
time performance information for hospital business processes. SCR supported SHS in building
advanced software features for the SF product vision system. Their marketing and sales staff use
the SF product vision system to stimulate the market at customer events, for request for
proposals, and at business meetings. The nature of SHS’s business needs to have new features
(typically workflows such as patient check-in, denial management, reverse a charge, …) is
characterized by the following constraints:
• Very strict deadlines for software delivery dependent on concrete dates.
• Often only high-level requirements for workflows are known.
• Late requirements and software design changes should be accommodated.
• The user interface has to be highly usable.
Using conventional software development processes (e.g. the waterfall model) would not support
strict deadlines and requirements exploration while developing the workflows. To address the
constraints, SCR has developed a software process model S-RaP that can address the time,

2. scope and user acceptance constraints in a very effective and efficient manner. It is based in
Extreme Programming (XP) principles [4,5] and adds two more key ideas: 1) Quasi-concurrent
execution of requirements development, user interface design; software design, build and test 2)
the use of a single software specification document (the storyboard) throughout .
Concurrent rapid prototyping process
for workflow- driven web in terfaces
T me
i
Project Planning Project trackin g
Refin ed St ory board ,
R ned U G
ef i I uide ines
l
Requirements
Draf t st orybo ard
D evelopment
U r equi emen t
I r s
So ftw are Requir ements in f orm o f story board s
Busin ess
f eatu res
( D af t
r
Storyb oard)
So ftw are Software Process
fe at res
u Final Release &
Start Bu siness Scope D efinition Sof tware D esign & Build Improvement End
( D aft
r
Delivery
Stor yboar d)
R n ed St ory board ,
ef i Workshop
Evolutionary Pr ot typ e
o
Use Cases
(Dra ft St ryboa r d)
o
UI Sc reen, U guideli e s
I n
UI D esign
Bi ir ectional Feedback
d
Output
R ned St orybo ard,
ef i
R fined UI gui e li es
e d n
Proce ss
Figure 1: Schematics of the S-RaP software process model (each of the core processes should
have iterations indicated).
The S-RaP software process consists of a set of core processes and support processes. S-RaP’s
core process are the Business Scope, Requirements Development; Software Design, Build and
Test, User Interface (UI) Design plus Final Release and Delivery. Support processes are
organized into Project Planning, Project Tracking and Software Process Improvement. It is used
throughout the paper as a guide to visualize where and how the issues occurred and how they
get resolved.
Using S-RaP, SCR staff, partnering with SHS, developed a series of workflows such as patient
check-in, guarantor follow-up, guarantor financial overview, denial management, batch
processing, a J2EE compliant user interface architecture, a contract engine, migrating a UI from
static HTML screens to JSP revamped design including database support as well as tools to
customize the dataset for customer demonstrations. The whole project had ten distinct releases
(usually three to six weeks long). Each of them was delivered on time and w/in budget.

3. Figure 2: SF product vision releases over 8 months
However, an adaptive software process model and a top-talent project team are not necessarily
sufficient to deliver highly time-pressured projects successfully. Only the effective orchestration of
people, process and technology factors working towards the goal of the project. The SF product
vision project faced a series of very difficult challenges concerning people- and project
management which are discussed in the next section.
3. Problems & Solutions to People and Project Management Issues
In general, the series of SF product vision projects commenced in similar ways: “Can you build
the following software features a, b, c by date x with a highly usable interface?” The features were
specified in varying degrees of detail from an existing financial/ administrative workflow that
needed to be redesigned in a new user interface look and feel (e.g. patient check-in), very high-
level requirements where only some of the major steps are identified (e.g. bed board or case
management concurrent review) to only a vague statement of what the workflow is called (e.g.
denial management).

4. Whatever is known about a software feature is captured in a storyboard, which documents the
workflow, screen design, data requirements per task flow step as well as the user interaction
sequence on a screen. Missing or incomplete requirements for a software feature are analyzed,
complemented and validated in requirements development. In parallel, the screens in the
storyboard are evaluated and the ones that need any work (re-) designed. Development receives
the storyboard, evaluates the technical feasibility and prepares estimates on how to fit the
software design, build, integration and test of the feature to meet the deadline as specified by the
customer. In design review sessions, critiques about the work in progress software prototype are
fed back for requirements/implementation adjustment. Finally, acceptance testing by the
customer representative provides an iterative loop for last adjustments to the implementation. In
this fashion, the SF product vision product prototype is iterated and requirements matured. The
outcome is a highly usable web user interface matching the defined requirements.
Subsequently, the people and project management issues that happened during the SF product
vision project are itemized.
3. 1 Problems & Solutions to People Management
Overall, the Soarian Financial product vision produced ten major releases with more than
160,000 lines of JSP/Java code, using a project team of twenty to thirty three staff members.. The
core team is five people consisting of a program manager, two senior and one junior software
architects plus a very experienced lead designer with expertise in hospital financial/
administrative workflows.
One of the well known wisdoms of software engineering is the people factor which can make a
software development endeavor succeed or fail. In the following sub-sections, topics such as
training needs, staff management broken down into project staffing, maintaining people
motivation and focus, people performance management, and last but not least people
communication.
Training Needs
In order to be able to develop the feature sets as requested by SHS, 28 staff were needed
additionally to the core team over the life-cycle of the SF product vision project. The people
joining the team did not have prior exposure neither in the Soarian Financial project nor the
healthcare domain. The key means to bring new hires up to speed was to
• give tutorial on the software architecture used and assign them a low-risk development
task to facilitate learning on the job.
• staff the sub-teams with experienced developers to allow knowledge transfer to
beginners.
• assign functional testing tasks initially to build domain knowledge.
In addition, these efforts were supported by the use of a searchable project mailing list and the
creation of a knowledge database. Overall, the core team spent approximately ten percent of their
working hours on teaching new hires.
Staff Management
Once new hires were up to speed, the overall in a dynamic environment needed to be managed
the way to impact positively the SF product vision project. Staff management in this paper is
about project staffing, maintaining people motivation and focus, people performance
management and people communication.
Project Staffing
Giving new hires three to four weeks or longer to get through an initial learning curve is possible
in conventional development projects where the time-to-market does not have to be achieved in
three to six weeks from initial requirements definition to deployment of the software feature.
Particularly, the core team found it difficult to find appropriate people to join the project team who
would fit into a very dynamic working environment putting up a lot of stress, but also excitement in

5. a contribution to enable SHS to be successful with their product demonstrations in the market
place. Further, not everybody could or would make the commitment to deliver on very tough
deadlines maintaining the high level of productivity and software quality.
In total, some forty resumes were reviewed and some fifteen interviews were carried out to hire
top-notch software developers. To quickly find great dedicated people outside of SCR, the core
team initiated a partnership with a global technology staffing agency. From the fifteen interviews
carried out, five consultants were engaged. Another part of the development force was selected
internally from within the SCR usually by referral or via networking. A total of twenty three SCR
staff and five consultants contributed to the releases.
Maintaining People Motivation and Focus
Hiring great people who perform is only part of the equation for success in software development
projects. The dynamics of a project and pressure to make every milestone took its toll on the
team. The core team who was steering the wheels of the ship was aware of motivation and focus
due to prior project experience in a smaller setting. Consciously, the leader of the core team
asked the other core team members to maintain the pulse on their people that they were working
with. Any issues on people burning out or too much stress was usually reported in the weekly
internal project leadership meeting.
To make sure that the sub-teams remained motivated to largest degree possible, one technique
was to rotate the project staff to do different tasks. For instance, we gave project staff the
opportunity to not only write code meeting tough deadlines, but also e.g. gather requirements,
carry out design reviews with the customer representative to validate a workflow implemented, or
run a software process improvement workshop. Providing people with such opportunities not only
taps into the creative juices of people but also builds credibility that the project management does
anything possible to alleviate the pressure and facilitate opportunities for professional and
personal growth. In total, some four process improvement workshops were carried out (usually
after each major release). This working session is a two hour event. The goal of the software
process improvement workshop is to identify improvements for people, process and technology
as well as vent concerns and issues. The output is a list of ten to fifteen improvements which are
transformed into an action plan. It is important that the project staff has ownership for
improvements implementation. In a meeting with the project leadership team, the low hanging
fruits having the greatest business impact are selected for implementation. For example, an open
source mailing list was suggested to allow rapid communication of code design patterns or code
snippets.
Furthermore, another technique to achieve team camaraderie is having a team pizza lunch
monthly, including the customers after a major delivery It is seen as a celebration and also
virtually “take a deep breath” before pressing on for another delivery In total, seven pizza lunches
were carried out.
As to the negative outcomes of the project, there were some issues of people chemistry making
them unable to work together in a sub-team. Three people needed to be separated and
reassigned to another team.

6. After reallocating the people, their performance was on track again. Unfortunately, three team
members needed to leave the team due to inconsistent performance and disciplinary issues.
Being consistent with the project staff is very closely observed by all team members. If staff
members are expected to perform on the top, it would be incompatible to keep people on the
project who do not deliver as expected. This would mean a big hit for the morale of the others
who are all “A” performers.
Early on in the project, it became evident that only “A” players could be hired for the SF product
vision project. The ideal “A” player for software engineering is technically very strong and has a
three plus years experience in the target software technology, is an effective communicator, a
team player but also is self-directed, goal-oriented and has a great potential to lead. User
interface designers to be “A” level payers need to be familiar with the technology of what designs
can be technically implemented, and is versed in creating relationships and bonding with the
customer. Additionally, interface designers must be prepared to engage with the development
staff for any user interface design issue popping up.
People Performance Management
To deal with a lot of people contributing to the delivery of this project, the project leadership
started to evaluate the each person’s performance in terms of technical skills, level of motivation
and team capability. The ranking metrics used was 1.. very poor, 2 .. poor, 3 … fair, 4 .. good, 5
... very good for every indicator. The evaluation was done by the project leader or the technical
lead of each sub-projects. The outcome of the people assessment was that every team member
on the project was between 4 and 5. Three team members assessed lower than four were
dropped from the next project. The people performance evaluation provided quantitative data
necessary to assign people for the next release and also to determine who would have customer-
facing opportunities. Throughout the year, three major people performance assessments were
carried out. Using this data, technical and project lead could put together teams that would
balance each other’s strengths and weaknesses for the benefit of the project. This also helped
minimize the risk of burning out people. Further, the project staff knew always how they were
performing due to a frequent dialog.
People Communication
One specific problem encountered by the project teams was to achieve a synchronization of the
requirements development, user interface design and software design, build + test. We needed to
keep in mind that we work in three quasi concurrent threads. A consistent communication
between all parties is a need that cannot be neglected. Although one single software specification
document is used, it cannot record all details of the semantics of what is being specified. Details
in a workflow (represented by a screen print and textual description of the user interaction) can be
misinterpreted and then development or user interface design efforts are wasted. This is
counteracted by the following means: Every design review is accompanied by a technical lead
and a user interface design lead. By doing this, technical implementation feasibility is evaluated in
parallel with assessing accuracy of the user interface design of the workflow. The technical lead
subsequently communicates the semantics of the workflow back to the pairs of developers
implementing a component of the SF product vision. Moreover, the technical lead encourages
team members to come to ad-hoc meetings if there is an issue that needed to be resolved, e.g.
on how to implement a secondary workflow.
To facilitate maximal interaction among software engineers, customer representatives/ subject
matter experts and user interface designers, being physically close to each other is significant.
Most of the development staff sits only two to five meters apart. For instance, one software
engineer, located on the another floor, joined the SF product vision several months ago. After
reviewing his performance, it was noted that he did not seem to be as productive as the other
staff that were physically closer together.
One of the technical leads suggested having him move closer to the rest of the team. Within one
week, the concerns regarding his productivity disappeared. Close proximity of the whole project

7. team facilitates the communication flow. It enhances rapid understanding of the semantics of the
workflows as early alerts when developers identify a critical issue that needs to be shared. Next,
the user interface design team is just down the hallway with a distance of twenty meters from the
software engineers. If there is any question respective the behavior of a user interface control, it
can be clarified w/in minutes. Brief hallway meetings resolved small issues before they became
big ones. Our experience so far has been that having a closed loop communication with all
stakeholders is one of the keys to the success of the S-RaP process. This facilitates minimizing
the risk of misinterpretation of requirements as specified by the customer.
Other means employed to make communication work amongst the teams was to clearly define
communication channels or single points of contact. The project structure designed established
the following roles: The technical lead of a team takes charge of any technical issue arising and
making sure that it gets resolved. Any user interface related questions gets taken care of by the
user interface lead which in turn submits user interface related design decisions to the project
sponsor for decision and approval. A project lead takes care of the tracking and reporting on the
project itself.
People issues and their solutions have a direct impact on managing the project in terms of
schedule, cost, and quality. The following subsection is all about the project management issues
that had the potential to jeopardize the project success as a whole.
3.2 Problems & Solutions to Project Management
Selecting the right measures to keep the project within schedule, cost and budget is a challenge
that is not to be underestimated for an effort with tight time constraints. Due to the nature of
SHS’s business needs, any failure on schedule would mean missing important sales
opportunities in the market. This fact put additional pressure on the leadership of the SF product
vision to do thorough impact analysis for changes.
The following problem categories surfaced during the life-time of the SF product vision: Problems
concerning new requirements, scope management, customer relationship; and people
performance management, project planning a well as project tracking and reporting.
New, Misinterpreted Requirements & Scope Management.
One of the most frequent problems to deal with from a project management perspective in this
project was the identification of new requirements which either came out of requirements
development, user interface design or software design, build and test. Due to the rapid
development of a software feature it is an expected phenomenon that requirements gathered at
the beginning of the release will mature over time as they are understood better. To identify
solutions that can cope with this fact is the use of the SF product vision prototype as a boundary
object itself [2]. The idea therein is to see the requirements as specified in a functioning
prototype. Customer representatives and subject matter experts get a hands-on feel for how the
workflow is being implemented. It allows experiencing the user interaction step by step through
the workflow as well as testing the usability of the system overall. Another source of new
requirements is a design review which involved the developers. They are meetings with a focus
on providing feedback on how the product is being perceived by the customers. Reviews help
drive development into a direction of maximizing customer satisfaction. From these reviews,
developers learned about missing steps in a workflow, missing data that need to be provided or
about clarifications about interactions that are needed to make the feature function. Over 100
telephone conferences with an average duration of one hour were carried out
Every new requirement was analyzed and re-estimated in terms of effort by all tech leads paired
with an impact analysis and the viability of fitting it into the current release plan. If there was more
than one requirement, the customer was asked to prioritize the new requirements. Next, the
project sponsor and the responsible project manager negotiated what could be done w/o
endangering the current delivery. About ten adjustments in the project plan could be made to
build in the extra requirement. Twice, it was not possible to adjust the project plan without risking

8. the failure on already committed dates. If that happened, the new requirement was put into a
feature list and built in one of the subsequent releases.
A second problem area was misunderstood and misinterpreted requirements. This was caused
by the speed of process execution and lack of time spent on clarifying the detailed semantics of
requirements. It happened twice with building new workflows. The result of the misunderstanding
and misinterpretation was a waste of development effort. By frequently reviewing the workflow
built in code with subject matter experts, the flaws in the design were caught at a very early stage
and corrected immediately. Another successful means is to maintain a continuity of a software
engineer on a single component because it allows leveraging the healthcare domain expertise
acquired by that engineer.
A third problem to deal with in the context of scope management were requests to develop two
additional releases in the short-term while maintaining the same level of commitment. One was a
three week effort which required four staff and another one which was six weeks effort that
needed four people. In order to address the short-term requests, it was not possible to hire new
people due to the learning curve they needed to go through. Therefore, the only way to address
the customer request was to take staff from the current running projects and substitute them with
new hires. To achieve this stretch goal to deliver two additional releases, the project leadership
needed to carefully re-evaluate the skills of all of the people and make them fit with the
requirements of the additional releases. At the same time, the project lead on the running projects
still needed to have enough staff to guarantee the schedule as expected by the customer. Each
new team got one senior team member as the lead for the new releases paired with junior staff.
Further, the switching of the people to new assignment in the very short-term created some
issues of focus. In total, eight out of twenty-five people got switched back and forth between the
sub-teams.
Project Tracking & Reporting
One of the key problems encountered in the SF product vision was the ability to track progress of
work accomplished and relate it to the deadline ahead. Short deadlines and the progress in the
project can only be tracked if there is a fine grained control to measure it against.
The project plans were planned around the idea of “Miniature Milestones” [3] which are two to
three days deadlines. They help to assess the risk of non-delivery of a software feature.
Figure 3: Sample project plan with Miniature Milestones

9. The miniature milestones paired with cross-interviews facilitated by the technical/ project lead of
the development staff provide the right set of data to evaluate plan versus actual. This provides
an accurate picture on the “real progress” (see figure above). Subsequently, appropriate steps
managing the projects can be taken. For example if the progress of development of one workflow
is late, there is an opportunity to shift development resources.
Another project management technique is to carry out a one hour weekly status report meeting
with the project sub-teams to keep the focus and provide a look-ahead to the next week’s
expectations. Also, the testing of workflows starts as soon as there is a small part of the workflow
implemented. It helps to obtain a “count” on the functional and non-functional software defects.
The count is taking into account to have enough time allocated for bug fixing. All in all, these
simple measures allow a further fine-tuning of the project plan to minimize the risk of non-timely
delivery.
Customer Relationship
SHS put great faith and trust into SCR’s capability to deliver the number of workflows, a new user
interface architecture for a new, highly usable web interface and database support. In order to
make sure that faith and trust are supported by facts, a very tight and close project reporting
structure was designed. It was all about managing the expectations the way according the
principle of “We deliver what we promise”.
The project’s toolbox contained the following: Continuous communication on the progress
achieved by means of design reviews with the customer representative/ project sponsor.
Additionally, every Friday a status report outlining the previous work week achievements, task of
the following work week plus issues and concerns was provided. On the following Monday or the
first day of the work, a project leadership teleconference was held to achieve two goals: Report
the progress from last work week and plan the following work week. That was necessary due to
the continuous involvement the staff from SHS to validate workflows built and also to get SHS to
do very early acceptance testing. In total, twenty eight leadership meetings of thirty minutes
duration were carried out. The fact that SHS could see an evolving functioning prototype
demonstrated visible progress and built credibility and good-will on both sides. Further
negotiations concerning new requirements became easier as our partner SHS perceived us as
trust-worthy and reliable.
From a project leadership perspective, the key is to have “No surprises” in time-pressured rapid
prototyping & development projects. Failing on the promise would have a very negative impact on
SHS’s business.
4. S-RaP Key Practices for Time-Pressured Rapid Prototyping & Development Projects
Over the lifetime of this project, the following key practices for rapid prototyping & development
using S-RaP were identified and applied to drive the development of this project:
• Use of single-artifact through software life-cycle: The storyboard is used to capture
requirements, UI design specification, coding specification and test case specification.
• Focus customer workshop: Is a quick way to obtain a start draft storyboard for a use case
of a software feature to be built.
• Miniature milestones: Is a defined date in a project schedule prompting a concrete result
in a software development project. It usually happens all two to three days.
• Integrated multidisciplinary software development teams: Customer representative/
subject matter expert, project manager, developers, UI designers work as an integrated
team capitalizing on diverse skills and experiences.
• Project leadership meeting: Is a 30 min. meeting at the beginning of each week with
attendance of the project manager, tech lead/ chief architect, project sponsor and the UI
design lead. The purpose of this meeting is to report progress on the work accomplished
and the planning for the current work week. It is a key tool to synchronize all project
stakeholders to assure compliance according the schedule.

10. • Design reviews: Is a meeting with attendance of the UI design lead, tech lead and the
customer representative/ subject matter expert. The purpose is to visualize the work in
progress and provide the developers with feedback and improvements. It is a key activity
to assure that the requirements are implemented as the project sponsor expects to
obtain. Quick turnaround of improvements visible in prototype builds confidence.
• Staff performance evaluation: Assessing how well people contribute on an ongoing basis
provides a useful tool to assign the best people to the most difficult components to
develop.
• Task rotation: This practice helps to avoid project staff burn-out due to the short
deadlines that have to be adhered to. E.g. a developer can become a requirements
engineer to work with the customer representative/ subject matter expert.
• Software process improvement workshop: Identify proactively improvements relative to
technology, people and process. The output of the workshop is used to improve the
effectiveness and efficiency of this software process model.
5. Conclusions & Future Research
Extreme programming and a flexible software process model like S-RaP can work together
synergistically. S-RaP provides a stable framework of reference in a highly dynamic software
development environment to manage people and project management very effectively. Applying
the practices, we have found effective such as the use of a single software specification
document, focus customer workshops, project leadership meetings, applying design reviews and
using software process improvement workshops as means to learning throughout the delivery
creates an atmosphere of focus and excitement for all project staff.
SCR will continue refining S-RaP and using it as the core model for another large Siemens
product line development project.
6. Acknowledgements
The authors would like to thank Robin Kavanagh, Cynthia Lazzari and Jamie Moretz from SHS
for the great collaboration on the Soarian Financial vision project. Without their help, feedback,
guidance and advice many of the workflows as well as user interface designs would not have
been implemented the way as they have been. An additional thank-you, we owe to the SCR staff
from Software Engineering, User Interface Design, Multimedia Technology and Integrated Data
Systems as well as our consultant team that were committed till the last minute on this endeavor.
7. References
[1] Beatrice Hwong, David Laurance, Arnold Rudorfer, Xiping Song; Exploring the Effectiveness
Potential of User-Centered Design and Agile Software Development Processes; CHI 2004,
Workshop Bridging the Gaps between HCI and Software Engineering I; Vienna, Austria, April
2004.
[2] Junius Gunaratne, Christopher Nelson, Beatrice Hwong, Arnold Rudorfer, Xiping Song; Using
Evolutionary Prototypes to Formalize Product Requirements; ICSE 2004, Workshop Bridging the
Gaps between HCI and Software Engineering; Glasgow, Scotland, May, 2004
[3] Steve McConnel: Rapid Development, Taming Wild Software Schedule, 1996.
[4] Kent Beck, Extreme Programming Explained: Embrace Change, 1999.
[5] Stephen Palmer, John Felsing: A Practical Guide to Feature Driven Development, 2004.