Agile Management of Research Projects in
the Contract Context
This study is based on the 30+-year experience gained while managing innovative
process control and business management projects . For these and similar
projects, their scope definition and budget estimation in advance was always the most
challenging task. Typically, if the estimated budget of any project is higher than the
other ones, the solution provider is recognized as inefficient in one way or another. But
there might be another reason if innovative projects are concerned, i.e. the provider's
know-how and extraordinary experience make a better assessment possible. Better
assessment always means higher budget in this context and, in a typical bid where
budget is the most important factor, it puts the solution provider in an underprivileged
position and leads to the “more stupid the better” syndrome.
For an innovative project, the main reason why its critical parameters are hardly
predictable is its innovative nature. From the definition, an innovation as a translation of
an idea or invention into a product or service that creates value is an exploration into
unexplored areas. The leader of the team must, therefore, face a high level of
The main aim of any invention application outcome is to further satisfy the needs
and improve selected processes. But in all cases it is a business process involving at
least two organizations: a customer and a solution provider that must cooperate under
a contractual relationship, i.e. a voluntary, deliberate and legally binding agreement
between them. The contractual relationship is evidenced by an offer, an acceptance
thereof, and a valid (legal and valuable) consideration.
To make the procurement process transparent, fixed-price and fixed-term offers are
usually expected to simplify the comparison and selection of a bid for contract award.
As a consequence, the quantitative nature of the comparison relaxes the responsibility of
the target company (customer) management involved in the selection process, which
makes the selection process offer-centric and neglects the uncertainty of the proposed
terms. In some circumstances it may cause an assessment of just a “wish list”, but not
a realistic proposal and lead to circular impossibilities:
1. It is impossible for the customer to prepare the specification because the
customer is unaware of the necessity of exploration.
48 From Requirements to Software: Research and Practice
2. It is impossible for the solution provider to prepare the offer as the
specification is inadequate and the unanswered questions can be addressed and
worked out as project goals only.
The procurement issues described above could be partially solved using direct
negotiations or the single-source acquisition method. Unfortunately, both suffer from
the non-quantitative nature of the selection process and usually are an exception to the
typical procedure. Nevertheless, as the quantitative assessment is difficult or even
impossible, they might be a better choice.
The discussion about the procurement process is out of this paper scope. However,
in spite of the selected procurement method, the question how to limit the budget,
determine the time frame and define the expected scope and quality in the contract is
There are a variety of methods supporting budget assessment, but it is always only
assessment as a result of the fact that the project scope is unpredictable. In most cases
unpredictability means that some aspects of the research and development work are not
calculated (are omitted) in the cost estimation, which usually leads to budged
underestimation. Appling an arrangement under which a solution provider (contractor)
is paid on the basis of actual cost (time and material contracts) alone puts the customer
into an unprivileged position because there are no measures that can be used to asses if
the paid workload is really required, i.e. it is relevant and within the scope of the project.
It could easily lead to endless projects, as there is always something to discover as a part
of the research and development activity. Especially in case of direct negotiations or
single-source acquisition method for fixed-price contracts the budget overestimation
could be enforced as a method to address the inevitable project unpredictability. For the
customer, both situations are usually inacceptable and a compromise must be worked
out. Detailed definition of the contract rules is far beyond of this paper scope, but it is
only proposed to assume that the contract imposes a budget limit and is paid on the
basis of actual cost. Additionally the solution provider is tasked with making the final
cost estimation on continuous basis to recognize the situation when the project budget is
put in danger. In this case the following options could be applied:
the budget is renegotiated;
the scope of the work is limited;
the project is canceled.
For the problem described above, the article proposes a methodology framework
that tightly couples:
Agile approach to dynamically control the work scope and time framework
Workload tracking to precisely control the value for money
Agile management is recognized as a methodology that helps us to guide software
development projects towards the most valuable outcome possible  . To address
this question the existing agile approach (sometimes called philosophy ) must be
implemented in the context of contract rules (section 2). It should be non-invasive and
effortless, but implemented as strictly observed rules described in a formal way by the
contract to control the development process with the goal to assure customer satisfaction
under the contract limitations. It is proposed to deploy it as a consistent solution (section
4) using supporting tools developed on the business process modeling basis (section 3).
Agile Management of Research Projects in the Contract Context 49
2. Agile Based Contract Rules
Generally, the innovative projects are aimed at improving the selected key performance
indicators (KPI) as a result of process control or business automation using novel
architecture, algorithms, business process patterns, software, hardware, etc. It requires
providing a variety of:
out of the box products,
custom services including designing specifications, developing, integrating,
testing, training, commissioning and supporting.
Usually the appropriate selection of products is an outcome of services and depends
on their quality and performance (the purchase procedure is beyond the scope of this
One of prerequisites for the achievement of the goal, i.e. real improvement in the
selected KPI, is the use of such solutions and implementation of such target solution
functionalities that the expectations of the parties concerned are met to the greatest
possible extent within the agreed time frame and cost limits.
Here the optimization of:
the scope of work that will enable the customer to achieve the business goal,
the implementation team's efforts to maintain maximum work efficiency and
quality of the provided deliverables, which, consequently, significantly reduces
is of crucial importance.
It is, therefore, proposed that well-proven practices derived from Scrum   
  methodology related to management of development and implementation work
within the project should be used. Scrum is proposed because it concentrates on the
management aspects, which makes the adoption process straightforward. The Product
Owner role defined by the Scrum methodology is also the best candidate to be tasked
with representation of the business objectives on the continuous basis during the whole
project lifecycle. A well-defined roles set proposed by Scrum could be also expanded
non-invasively by adding roles in charge of taking care about the formal and legal
course of the agreement and controlling of the work environment.
On the basis of agile philosophy it is assumed that optimization can be achieved if
cooperation is based on the following assumptions:
Cyclical nature - work is carried out in pre-scheduled time cycles (milestones),
which allows the customer to control the scope and progress of work and value
Mutual trust – the application of methods and tools to ensure great
transparency in the process of developing and implementing new findings and
deliverables, which allows the customer to fully monitor work.
50 From Requirements to Software: Research and Practice
It is proposed that the following business model should be used to carry out tasks in the
area of cooperation:
Under an agreement of business cooperation (framework contract) concluded
for an indefinite or long period of time, the solution provider will implement
and maintain solutions in the area of collaboration stipulated in the agreement.
Further development of the implemented solutions will be effected as an
extension to the basic scope of the agreement.
To ensure appropriate competitiveness conditions, the rules of Scrum project
management will be implemented.
The contract as a formal set of statements provides business environment for any
activities related to the development and deployment of project deliverables. The
cooperation agreement will define the organizational framework and basic accounting
principles of the further work.
In all projects referenced in Section 1 as the experience source the target was
reached as a series of contracts. For the innovative research projects it is a typical
behavioral pattern as exploration into not well-known areas usually yields discovery of
new ones also worth exploring next time. To limit this naturally infinite process there
must be defined performance key indicators to assess quantitative and qualitative
objectives before making decision in this respect.
It is, therefore, proposed to define the contract as a foundation for carrying out a
series of loosely coupled projects, instead of a series of contracts. The main aim of the
contract is to define basic rules related to new project scoping, budgeting, scheduling
and progress controlling.
The proposed approach is mutually beneficial. One of the benefits for the customer
is an obligation of the supplier to provide appropriate resources to address any problems
in the area of cooperation. This model is also beneficial for the supplier because it offers
prospects for a continuous fixed-term solution delivery process.
It is proposed that the contract has to define procedures compatible with Scrum
project management and consequently the following roles are featured as a part of
Managers (one for each party) - are responsible for the formal and legal course
of the agreement and controlling of the work environment.
Business Owner (customer's employee: like Product Owner in Scrum
methodology) - is responsible for defining and prioritizing requirements in the
initial phase of each milestone (iteration in Scrum methodology) to ensure
maximum improvement in the efficiency of business processes.
Team Leader (provider's employee: like Scrum Master in Scrum methodology)
- is responsible for cooperation between the Development Team and the
Business Owner and for compliance with the contract rules governing
management of the project.
Development Team (provider's employees) - is responsible for selecting
requirements (scope of work) to be fulfilled within a milestone from the Basic
Product Backlog (equivalent to Product Backlog in Scrum methodology) and
Agile Management of Research Projects in the Contract Context 51
the milestone length at the beginning of each milestone and for the transfer of
the developed deliverables to the Business Owner before the milestone end.
The names defined by Scrum are changed to emphasize the responsibility
modification. For example the Team Leader must not only follow the Scrum rules but
also take care about contract limitations and obligations. It requires some familiarity
with the local legal system. The Business Owner is additionally responsible for
validating of the workload settlement in the context of the selected milestone scope.
Work scope selection, designing, preparation of deliverables (software,
documentation, graphics etc.) and deployment (installation, configuration, testing, and
documentation) will be effected in specific time cycles called milestones. The milestone
length should be fixed each time and should not exceed 2 months. It is the upper limit
that should be a compromise between the development needs and business bureaucracy
Each project begins with defining the direct target, initial functional requirements
(a set of required functions) and non-functional requirements (a set of required solution
features) that make the Basic Product Backlog; that backlog gives grounds for selection
to determine the scope of further work in the next milestone.
The Development Team selects requirements at the beginning of each milestone, on
the grounds of their priorities agreed with the Business Owner and the scope of work
selected to be carried out in that milestone, which (according to the Scrum rules)
remains unchanged for that milestone. The milestone scope selection is a negotiation
process based on the business objectives represented as requirements priorities and
technical limitation analysis. Unfortunately, it usually causes a longer iteration cycle
because it is not enough to provide something that works, as it has to work also for
business. Good examples are code refactoring in software development or design
documentation preparation. For business, this work provides no value at all so if
required it must be included as negligible part of the whole milestone scope of the work.
The Development Team hands the products of the completed milestone (including
deliverables such as software code, documentation etc.) over to the Business Owner at
the milestone end.
Any work that has not been completed during the milestone for any reason returns
to the Basic Product Backlog and is subject to priority analysis and technical
dependencies for the next milestone. All new requirements defined in course of work
are entered into the Basic Product Backlog as well.
The reported team workload and the value of granted licenses and copyright form
the basis for settlement. The workload is settled on the grounds of monthly reports
submitted to the Business Owner and the Managers. It is calculated at the common
basic rate per man-hour. It is important to apply the common basic rate with the goal of
mitigating customer's influence on association of the team members and tasks.
On completion of the project, the customer gets a license granting him a right to use
software and supplied deliverables.
In order to minimize the risk of underestimation or overestimation of the project
budget in case there is a great deal of uncertainty about the research field, a feasibility
study, design work or a pilot application may be executed in order to determine:
qualitative (direct and indirect) business goals,
technical solutions optimal against selected KPI,
52 From Requirements to Software: Research and Practice
necessary investment outlay on the purchase of third party products,
own and third party workload,
maintenance costs of the proposed solution,
selected economic efficiency indicators,
risk analysis as a component of risk management; it consists of identification
of possible negative external and internal conditions, events or situations.
Additionally, the risk of budget estimate incorrectness can be minimized thanks to:
the work cyclical nature, i.e. the possibility of finding an error at an early stage
of project execution,
billing work intensity, which balances risks of both the partners and makes
overpayment in case of overestimate impossible,
maintenance work that ensures the continuity of system operation through the
quality of the rendered services instead of a guarantee; it does not exclude
guarantee commitments for certain products.
Successful implementation of the proposed methodology requires appropriate measures
Implement billing principles.
Support defined roles and management rules in a consistent way.
Promote mutual trust.
All are closely related to rules that must be concluded by the contract. There is no
doubt that it requires appropriate tool selection generating reports formally acceptable
to the customer Account Department to effect the settlement and effectively support
management rules at the same time. The main purpose of this section is the definition of
requirements that have to be met by the tool.
A variety of out of the box products supporting implementation of the Scrum
management rules are available on the market. A set of primary prerequisites for the
proposed approach must be defined to select one of them or decide to develop a new
one. All of them can be grouped into the following categories:
Business processes: to organize the work.
Data model: to represent vital information.
Functionality: to process the data according to the business process rules.
Even though the detailed description of all the prerequisites is beyond this paper
scope, the topics most important to the proposed methodology implementation will be
discussed in the following subsections in hopes of making the decision process easier.
The discussion could also be used as a starting point to expand the existing products by
the end user or vendor with the aim of implementing the contract rules proposed in
Section 2. The requirements defined in this section are vital for the decision as to how
the presented methodology should be deployed in the case study presented in Section 4.
Agile Management of Research Projects in the Contract Context 53
Any business process is a series of logically related activities or tasks (such as planning,
research, development, design, testing, documentation, etc.) performed together to
produce a defined set of results. According to the Business Process Model and Notation
specification  a business process can be formally modeled as:
Roles: a set of actors engaged in activities
Activities: a set of actions and events
Relationships: a set of workflows and roles communications
Artefacts: a set of data objects, groups and annotations
For the methodology proposed in this paper, the roles together with their
responsibilities and expected behavior as defined in Section 2.2 must be transformed to
actions and workflows.
Communication of roles is crucial to the performance of actions and final results
quality for the kind of business processes discussed in this paper. The main feature of
this communication is unpredictability of forms and formats selected for this purpose by
the Development Team. For example, brainstorm results may be documented as a thread
on a discussion board, picture of notes/diagrams on a white-board or meeting minutes.
Unfortunately, the results remain often undocumented at all and the supporting tools
must, therefore, engage the Development Team to select one and provide documentation
for the most important collective actions.
On the other hand, the selection of forms and the necessity of preparing
documentation must follow the general agile management principles, for example
documentation of a Development Team daily meeting can be recognized as time wasting.
Business processes aimed at accomplishing an innovative project may produce
a variety of results but intellectual properties are usually the most important ones, i.e.
discoveries, formulas, inventions, knowledge, registered designs, software, know how,
etc. In spite of their intangible nature they must be documented to be useful as an
outcome of the project governed by contract rules. In this case documentation is a
representation of something that has no physical existence otherwise. Documentation or
other forms of intellectual property representation are of special importance as the
contract must not be used to describe any form of abstraction.
Business processes are usually expected to produce results of the highest possible
quality level. Because the Development Team’s outcome is intellectual property (some
kind of abstraction) the question how to improve the quality arises. To address this
necessity it is proposed to combine the following tracking functionalities into one
Deliverables including code
Tasks and issues
Entities representing the process state
Deliverables tracking is used to maintain current and historical versions of files
such as the source code, web pages and documentation. The tasks and issues tracking
mechanism allows the team members to follow the sequence of actions undertaken to
fix the problem or obtain the requested result. An association of each reported workload
with a task and team member should be a good motivation to improve individual
54 From Requirements to Software: Research and Practice
performance and engagement  . It is worth noting that during the task lifecycle
it typically changes the current owner many times. Any record describing a workload
must, therefore, preserve information about the associated team member's activity. The
tracking mechanism should also facilitate diagnostics and finding workaround solutions.
An entity is a collection of properties representing selected data – a class - of the current
Contract settlement and, finally, billing requires accuracy. To put trust on the accuracy,
the settlement mechanism must be easily verifiable on a continuous basis, and
unambiguously associated with the related workload.
In spite of the management rules governing the project, the team work is organized
on the task basis. Tasks are defined to describe work needed to fulfill requirements
planned for the selected milestone. This relationship between Task and Resources is
dynamic and can be changed several times during the task lifecycle. Each reported
workload must be associated with a relevant task. To promote auditability and team
members engagement, the reported workload must be also accumulated for each
member individually and associated with the task. Both associations are permanent for
the whole task lifecycle. A follow-up class diagram is shown in Figure 1.
Figure 1 Task relationship diagram.
To successfully finish any milestone, all associated requirements must be
accomplished. Before being selected for a milestone all requirements make up the Basic
Product Backlog. The Business Owner should be able to add, update, prioritize, split,
merge and categorize them.
The contract billing rules use Project class entities to represent:
The Project is, therefore, a collection of Milestones (Figure 2). This way
functionality counting the reported workload for the project can be easily implemented.
Agile Management of Research Projects in the Contract Context 55
The requirements planned for any milestone and related tasks can be used to manage
and monitor the project scope. To facilitate this process and allow all participants to
monitor the work progress, the entity of the Task class has to expose status information.
Each task is a collection of actions reported as workload items and should be defined in
terms of the baseline start and end times planned to realize it and actual timing
information collected from the underlying Workload records.
Figure 2 Project relationship diagram
To support diagnostics and maintain quality, the model shown in Figure 2 has an
additional relationship between the Task and Milestone classes to provide
supplementary tracking information that allows the current owner to recollect situation
at the point in time it was created. Registering all modifications of entities shown in
Figure 1 and Figure 2 should be required for the same purpose.
According to Section 2.2 the Contract class is a collection of Projects (Figure 3).
Its role is to provide a set of rules governing the engaged parties cooperation. Therefore,
together with the surrounding entities, it should provide information allowing mangers
Synchronize and schedule work realized as separate projects
Optimally use resources
Sometimes splitting even closely related work is necessary in case a different
Business Owner must be assigned. Engaging the same team into many projects must be
limited by the working hours – team capacity. Theoretically the optimal load of the
team as a whole is near 100% potential capacity limited by the working hours. To fulfill
this requirement the Estimation class is added to the model (Figure 3). At the planning
stage its role is to establish the Development Team of a project and assign estimated
workload to the team members. It is worth noting that resources usage must be
monitored for each individual separately irrespective of its teams association.
56 From Requirements to Software: Research and Practice
Generally speaking, implementation of the methodology proposed in this paper requires
functionalities that may be grouped as follows:
Contract management centric
Project management centric
Product management centric
People hate to track time, but it has to be done to provide the project settlement
mechanism. Time tracking should be fast and easy, however, since progress reports and
contract billing are based on accurate time records, it must prevent team members from
reporting workload overlapping in time and associated to more than one task. To
facilitate workload reporting, the user interface may offer functions like stop-watch,
workload entities snapping, common activity reporting, etc.
The workload tracking result may also provide a very good feedback that can be
used for further improvements of the project scope planning, budgeting and personal
improvements. A good source of feedback making a common experience foundation for
planning is a well-suited periodical report generation mechanism. A different solution is
required for the analysis of the individual engagement. It could be obtained by using a
personalized dashboard that integrates workload reporting and monitoring of reported
Figure 3 Contract relationships diagram
The project management has to be supported at least by:
Work organization and planning
Team member communication and documentation
Agile Management of Research Projects in the Contract Context 57
The main challenge faced up by innovation deployment projects is
commercialization of the results. Even if a result is launched as a prototype, a release
procedure and lifecycle management support must be considered. It requires documents
versioning, i.e. assigning either unique version names or unique version numbers to
unique states of document sets (e.g. computer software).
4. Case Study
For a successful deployment of the contract aware project management methodology
presented in this paper, the following nonfunctional requirements are of great
Remote access to the main functions for all parties.
Possibility of offering the application as a service (cloud computing).
Typically, parties to a contract are not sited nearby and, hence, are not able to use
common IT infrastructure. They have to use remote access to common resources instead.
Moreover, it must be assumed that contract parties are independent organizations and,
therefore, the application used to support management must be offered as a service to at
least one of them. Consequently, the contract rules must also cover a Service Level
Agreement and infrastructure must meet the cloud computing requirements.
Agile Workload Tracker  software package is a solution meeting the
requirements presented in this paper. It was designed as a customization and extension
of SharePoint 2010 (Microsoft's widely used collaboration software) instead of
developing the application from scratch. It is an Internet-based and cloud computing
ready platform providing a variety of out of the box functions dedicated to support team
work, including documents management and workflows.
Additional functionality dedicated to supporting the proposed methodology has
been implemented using a SharePoint server and client site application program
interface (API). Both are very powerful foundations for the deployment of custom
functionality. Using reusable software mitigates development costs and locating the
functionality in a cloud mitigates deployment and maintenance costs.
Using SharePoint only the software code versioning and modification tracking are
not satisfactorily supported. Fortunately, API and email processing service offered by
SharePoint make the integration with existing versioning software straightforward.
Since 2006 an independent workload tracker tool has been developed and successfully
used to improve research team performance in a number of projects, e.g.    as
the result of:
Controlling the engagement of team members in particular contracts.
Measuring member's effort related directly to contracts in comparison with
time spent on general operational activities.
The idea was to create and apply a team motivation mechanism.
58 From Requirements to Software: Research and Practice
Since 2011 a limited version of:
Agile project management rules based on the Scrum principles described in
Tools supporting project management and workload reporting described in
has been used internally as a basic management methodology in a projects aimed at
deploying a family of solutions   (contracted by a company from the fast moving
customer goods industry) with the main goal of limiting the scope of the research and
development and gaining the prospective customer. Because the solution was limited to
internal use only, to mitigate the project uncertainty the first stage was dedicated to
prepare design documentation to precisely define the project scope and deployment
environment. Starting form a few pages of initial specification provided by the customer
to process the procurement procedure the 600 pages professional design documentation
was prepared providing:
Target domain-centric business process model to define roles, activities and
main objectives of the proposed solution.
Functional and non-functional requirements to define the scope of the project.
Use cases models to figure out how the requirements are to be fulfilled.
Coverage matrix to make sure that all requirements are addressed by at least
one use case.
Implementation and deployment models to make sure that the final solution is
applicable in an existing environment.
Unfortunately up to now no one have read the documentation in details. The
specification was almost neglected and recognized as prepared by the developers for
developers only. Fortunately the documentation was used partially by the team as a road
map helping to avoid decisions leading to blind ends. Finally, the documentation
usefulness and its positive impact on the project performance are hard to be proved but
there are no doubts that this approach was unpractical for this project at all.
Table 1 Team projects comparison.
The key performance indicators for the team involved and its projects aiming at
deploying the mentioned above products family are presented in Table 1. In the table
the budget limit and reported workload are expressed by normalized values to minimize
the influence of condition fluctuation over years and does neither represent directly real
budget nor workload (non-disclosure limitations). All projects are contracted and
realized on a fixed-price basis in spite of the fact that the contract allowed adaptation of
Agile Management of Research Projects in the Contract Context 59
the budget in case of any need to change requirements significantly. The team members
are involved in other activities at the same time. To make auditing possible, i.e.
reporting daily workload of individual members, all working hours are reported and
allocated to separate projects.
From this table we can learn that the financial performance for Project 1 and
Project 2 was not satisfactory. At the same time the customer satisfaction was also far
from expectations in spite of efforts spent to obtain a better result. Because the overall
conclusion of the survey was: “Some improvements have to take place to continue
cooperation” at the end of 2012 a new agreement was made under the assumption that
new projects should be contracted applying the rules described in this article, i.e. agile
management embedded in the contract rules.
After applying new contract rules in the early 2013 an extraordinary improvement
of the projects key performance indicators proves that using the agile approach alone for
fixed-price contracts does not guarantee a satisfactory solution. It must be also noted
that the customer satisfaction rated as an index 0-100 reached the max value 100, i.e.
overall conclusion of the survey was “cannot be better”.
The innovative process control and business management research projects aimed at
providing solutions that cannot be just a copy of a well-known „technical pattern” suffer
from uncertainty and are recognized as a high risky business activity. It is caused by the
work scope that is hard to be predicted and described as it must embrace exploration of
critical areas not jet discovered.
The paper presents the methodology and tools that can be used for calming down as
a result of a tight coupling of:
The Scrum project management methodology.
Workload, tasks, and source code tracking.
Appropriate legal instrumentation.
A set of software tools and dedicated workspace to improve trust and support
seamless control of defined principles, operational coordination, and make the
cooperation transparent for all parties.
The selected practical results are also presented as a use case analysis. The case
study shows that using the agile approach alone does not improve the business
efficiency and customer satisfaction. It can be seen that the real improvement is
achieved after converging selected agile management and contract legal rules including
but not limited to the workload settlement.
The presented result leads to a very interesting question of what is the cause that
has a major impact on the business performance and customer satisfaction improvement.
To answer this question independent research must be undertaken, but it is worth noting
that applying the new approach changed the role of customer representatives
Before applying the proposed methodology they are responsible for auditing of the
final output for conformance to technical, reliability, maintainability, and performance
requirements. It leads to arguing and arguing the question “why a …..
60 From Requirements to Software: Research and Practice
functionality/feature is not supported” with the Team Leader gives always the same
answer “because it is not included in the specification, which has been already approved
by the contract parties”. From the discussion in Section 1 and 4.2 we know that
authoring the specification and making it comprehensive both for the end user and
development team is an unrealistic goal and unpractical approach for many reasons.
This limitation is usually taken as an opportunity to assume that there are “obvious”
requirements that must be fulfilled by any professional team regardless of whether they
are in the specification or not. Main concern is that we have not adequate measures to
distinguish obvious and not obvious requirements at the commissioning stage of any
project. Any discussion with the customer then becomes slightly difficult.
After applying the methodology proposed in this article the contract representatives
become active members of the development team contributing to the selection of the
research directions and scope of the work. At the same time they must share
responsibility for an overall project success. It changes seamlessly the project into an
adaptive process relaying on the customer involvement on the continuous basis. If that
is the case new requirements are also formulated by the development team. The team’s
proposals like “maybe this … functionality/feature will be useful” are replayed by “yes,
provided we have budged and time to accomplish it”.
Finally the above discussion can be concluded that the methodology presented in
this article is a proposal of a practical implementation of adaptive processes  in the
context of real contract limitations like a fixed price.
 CAS. Cfis-1 -flight inspection system of the radio navigation aids.
 D. Arendt and M. Postol. Real-time multiprogramming system for mine control centre.
Microprocessors and Microsystems, 14(1):39–46, 1990.
 M. Postol. Large scale distributed process and business management integration. In 14th International
Congress of Cybernetics and Systems of World Organisation of Systems and Cybernetics, Wroclaw,
2008. Politechnika Wrocawska.
 M. Postol. Real-time communication for large scale distributed control systems. In International
Multiconference on Computer Science and Information Technology, 2007.
 CAS. Shepherd application; optimal management of inbound and outbound deliveries.
 M. Fowler. The New Methodology. http://martinfowler.com/articles/newMethodology.html, 2013
 M. Rizwan J. Qureshi. Agile software development methodology for medium and large projects.
Software, IET, 6(4):358–363, 2012.
 K. Beck. The agile manifesto. www.agilemanifesto.org/principles.html, 2001.
 D. Jamieson, K. Vinsen, and G. Callender. Agile procurement and dynamic value for money to
facilitate agile software projects. In 32nd Euromicro Conference on Software Engineering and
Advanced Applications, SEAA, pages 248–255, 29 August 2006 through 1 September 2006.
 J. Shore and S.Warden. The Art of Agile Development. O’Reilly Media, Inc.,, Sebastopol, 2007.
 Object Management Group. Business process model and notation. http://www.bpmn.org/, 2013.
 K. Schwaber. Agile project management with Scrum. Microsoft Press, Redmond, Wash., 2004.
 A. Cockburn and J. Highsmith. Agile software development, the people factor. Computer, 34(11):131–
 C. De O. Melo, C. Santana, and F. Kon. Developers motivation in agile teams. In 38th EUROMICRO
Conference on Software Engineering and Advanced Applications, SEAA 2012, pages 376–383, 2012.
 CAS. Agile workload tracker software. http://www.cas.eu/Products/AWT.aspx, 2015.
 CAS. IPR application; electronic inward processing relief. http://www.cas.eu/Products/IPR.aspx, 2015.