Russian Space Agency Project Management Systems

From SEBoK
Jump to navigation Jump to search

The Development of a Real-Time Complex Adaptive Project Management Systems

Background

The essence of every management system should be the same: the allocation of human, physical, financial and intellectual (knowledge) resources to demands (tasks) with the aim of increasing the specified Enterprise Value, where the Enterprise Value is a system of values such as profit, market share, business sustainability, quality of service to customers, quality of working conditions for employees, quality of life in the community, etc. The key difference between the management of a business and management of a project is that businesses are continuously evolving processes whilst projects have specified beginnings and ends.

Standard challenges for project management are:

  • Stringent budgets and deadlines
  • High competition for limited resource availability such as up-to-date domain knowledge, skills and advanced productivity tools
  • Functional organisation, which inevitably impedes interdepartmental cooperation
  • Bureaucratic management, which is more concerned with lines of command and reporting than with the full use of project member’s initiative and creativity and which negatively affects their motivation
  • Rigid project planning, which leads to a rapid divergence between the project plan and reality

Large enterprises commonly operate several projects concurrently. What is best for an individual project it is not always best for the enterprise and therefore it is necessary to implement coordination of concurrently run projects with the objective of significantly increasing Enterprise Value.

There are two new key problems, which the 21st century brought to us.

The first is the rapidly increasing complexity of the Internet-based global market, which creates frequent unpredictable disruptive events. This requires real-time adaptive project management, for which there is at present no precedent.

The second is the replacement of capital with knowledge as the key business resource in the economy in which the wealth created by knowledge services is greater than wealth created by producers of goods. There is at present no management system capable of discovering, processing, storing and allocating knowledge to project tasks.

Purpose

The client for this case study was one of the key space technology organisations in Russia, their equivalent of NASA, which operates, at any time, many concurrent mission critical projects.

The purpose of the project management system was to enable the client to effectively manage several related projects (at least ten), collectively contributing to the specified Enterprise Value, with the following requirements.

  • Each project may consist of up to 5,000 constituent tasks
  • Project members may have different backgrounds and skills and may belong to diverse business cultures
  • Project members must have an opportunity to contribute to decision making processes, which affects their domain of work (distributed decision making)
  • Both project management and project members must have readily available and up-to-date information on, respectively, project and individual progress, productivity and achievements of goals
  • The allocation of resources to tasks must consider 4 types of resources, namely, human, physical, financial and knowledge
  • Availability of resources for and constituent tasks of each project may change with short notice and these changes must be rapidly incorporated into the system
  • Projects will be subjected to frequent disruptive events such as non arrival of expected orders, arrival of unexpected orders, sudden and unforeseen emergence of external/internal competitors, cancellations, changes in task specifications, delays, failures, no-shows, etc.
  • Rules and regulations governing projects are likely to change rather frequently and any change in rules and regulations must be incorporated immediately and easily into the relevant project management system
  • Any discrepancy between project plans and reality in the field must be continuously monitored and rapidly detected and reported
  • Projects may cooperate and/or compete for resources in order to increase specified Enterprise Value

A thorough analysis of the client’s requirements led to the conclusion that it is necessary to develop a real-time, complex adaptive project management system capable of cooperating and/or competing with other systems, with the overarching goal to continuously increase specified Enterprise Value.

The new system would replace a number of stand-alone, manual or semi-automated project management systems with inadequate monitoring of progress and productivity.

A thorough analysis of contemporary practices showed that such a transformation had never before been achieved. To the best of the team’s knowledge, there were no real-time project management systems in existence anywhere in the world.

Challenges

This particular undertaking had a number of challenges.

The most important challenge was the resistance to change by client’s managers. The new system with its progress and productivity monitoring capabilities threatened to expose inefficiencies and was not universally welcomed. Two approaches were planned to manage this challenge: the first was education of participants and the second, a proposal for a new payment structure which related salaries to meeting of targets, as reported by the new system.

The scale of the proposed network of systems was an even more important challenge, especially because all projects were mission critical. To manage this challenge the plan was made to adopt an evolutionary development strategy. The first step was planned to be a fully engineered prototype with a limited functionality, which would be extended into the first project management system only after a complete acceptance by the client that the prototype was capable of delivering its limited functionality as specified. The network of project management systems would be grown step by step.

The multi-agent technology, which underpinned the system, was well understood by the team, and a methodology for managing complexity (Rzevski and Skobelev, 2014) of the task was in place.

Systems Engineering Practices

Overview

The complexity of client’s projects ruled out all conventional project management practices and systems. Instead, for every project, the team designed a complex adaptive project management system, based on multi-agent technology, capable of meeting client requirements.

The system consisted of the following major components (Rzevski and Skobelev, 2014):

  1. Knowledge Base containing domain knowledge relevant to the client’s project management processes
  2. Multi-agent Virtual World which models the Real World of projects and is capable of managing real-world complexity
  3. Interfaces between the Virtual and Real Worlds, which enable the Virtual World to, in-effect, manage the Real World, with or without human intervention

Knowledge Base

Examples of Classes of Objects in the ontology are: Enterprise, Organisational Unit, Project, Task, Project Member (Human Resource), Hardware (Physical) Resource, Document, Software Resource, Knowledge Resource and Process.

Examples of attributes are, for Task: Content, Cost, Duration, Deadline and Preferences; and for Project Member: Organisational Unit, Competences, Profile, Schedule, Current Task, Salary, Achievements and Preferences.

A fragment of enterprise ontology is shown below.

[IMAGE]

Virtual World

Examples of agents that populate the Virtual World include:

  • Task Agent, whose objective is to search for the best resources capable to meet its requirements
  • Human Resource Agent, whose objective is to get the best possible task, which will keep the project participant fully occupied, provide opportunities for bonuses and/or enable the participant to learn new skills or get new experience
  • Physical Resource Agent, whose objective is to maximise resource utilisation
  • Project Agent, whose objective is to maximise Project Value
  • Enterprise Agent, whose objective is to maximise Enterprise Value

All decisions are made through agent negotiations, as exemplified by the following process:

Task Agents send messages to Human Resource Agents with required competences inviting them to contribute to task fulfilments. Human Resource Agents that are available send their bids. Task Agents offer project participation to those Agents that sent the best bids. Bids are subject to negotiations between affected agents.

A new Task Agent is created whenever a new task is formulated or a previously allocated task is modified. The new Task Agent consults ontology to find out what are its objectives and how to achieve them, and proceeds to send messages to selected Human Resource Agents inviting them to bid for project participation. It is very likely that this invitation will result in re-scheduling, giving an opportunity to Human Resource Agents that were not fully satisfied with their previous allocations to improve their positions. Remuneration, including bonuses, if any, is calculated on the basis of project member participation and achieved results. Enterprise members may participate in several projects.

The allocation of physical, software and knowledge resources is done in an analogous manner. Advanced methods (Rzevski and Skobelev, 2014) have been employed to maximise effectiveness of agent negotiation, such as, virtual microeconomics, agent satisfaction, agent proactivity, enterprise agents, swarm cooperation, etc.

Decisions on allocation of resources to project tasks are made using multiple criteria, for example, decreases in completion time, increases in quality and reducing identified risks, as illustrated below.

[IMAGE]

Connecting Virtual and Real Worlds

The project member dashboard is the key link between the system and the project member. The exchange of information that could be conducted using the dashboard include:

  • Negotiations of task content, risks, deadlines and budgets
  • Acceptance/rejection by the project member of offered project tasks
  • Inputs by project members of unexpected disruptive events and comments during the project
  • Reports by the system on the project member performance in carrying out accepted tasks

The system may decide to engage two or more available project members in competition with each other to secure an agreement on the acceptable task performance.

The other key link between the virtual and real worlds is the project managers dashboard, which displays detailed project performance data in the form of various diagrams and Gant charts and allows the manager to examine or modify decisions made autonomously by the system.

Lessons Learned

The first real-time complex adaptive project management system was commissioned and deployed by the client in 2014 achieving the following results:

  • 10% to 15% increase in project member productivity;
  • 3 to 4 times reduction in manpower required for project scheduling, monitoring and coordination;
  • 2 to 3 times reduction of response time to unpredictable disruptive events;
  • 15% to 30% increase in the number of projects completion on budget and in time;
  • A significant increase in project member motivation;
  • A possibility to increase the number of projects operating in parallel without increasing the number of employees.

References

Works Cited

Rzevski, G., Skobelev, P., “Managing Complexity” WIT Press, New Forest, Boston, 2014. ISBN 978-1-84564-936-4.

Primary References

Rzevski, G., Skobelev, P., “Managing Complexity” WIT Press, New Forest, Boston, 2014. ISBN 978-1-84564-936-4.

Additional References

None.


< Previous Article | Parent Article | Next Article>


SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus