Intelligent Software Project Risk and Resources

What is intelligent software project management?

Intelligent software project management, in this paper, is a proposed web-based system that joins risk prediction and task assignment. Risk work uses anomaly detection and supervised learning. Assignment uses natural language processing and reinforcement learning. The design is meant to live inside Agile teams, not to invent a new ceremony. Heuristics and rigid rules are the thing it tries to replace.

Viktor Velikov and Galina Ivanova presented that design at the 2025 International Conference on Computer Systems and Technologies (CompSysTech), an IEEE meeting held 27 to 28 June 2025. The eight-page research article is also listed on research article pages in IEEE Xplore as document 11136946. The tone of the abstract is forward-looking: the components “will” detect, assign, and be tested. Read it as an architecture paper, not as a finished product trial.

That future tense is useful. A lot of AI-in-PM writing sells a dashboard that already “reduces failure by 30 percent.” This one is more careful. It names a gap (risk tools and staffing tools rarely share a brain), proposes two components, and sketches how to check them with benchmarks, simulation, and A/B tests. If you run a delivery org, that is closer to how you would actually introduce a model than a glossy case study with no baseline.

"Risk and staffing are usually two meetings. This paper's bet is that they are one system."

The rest of this piece unpacks that bet. You will see how the risk side is supposed to work, how the allocation side reads tickets and balances load, and why Agile integration is treated as a requirement rather than a nice extra. You will also see how the authors want the idea tested, which is the part most architecture papers skip.

Why are risk analysis and resource allocation still stuck?

They are stuck because teams still rely on gut feel and fixed rules. A risk log is updated after the fact. A board is assigned by whoever speaks first or by a spreadsheet of names. Those habits do not scale when stories, skills, and load change every sprint. The paper's opening claim is that this subjectivity is still the main failure mode.

Subjective heuristics are not always wrong. A senior lead can smell a bad dependency. The problem is coverage. One person cannot watch every ticket, every leave request, and every slipping test suite. Rigid rule systems fail the other way. “No one owns more than five stories” ignores that five tiny bugs are not five features, and that one person may be the only one who knows a module. Rules that cannot see context become the next bottleneck.

The authors also argue that risk and allocation are treated as separate products. A PMO buys a risk tool. Engineering buys a planner. Neither feed informs the other in time. A predicted delay that does not trigger a reassignment is just a red badge. A reassignment that ignores rising defect risk is just churn. Unifying those two issues is the paper's stated contribution: a cohesive architecture instead of two more plugins.

If you already read surveys of AI in IT project decisions, this paper is more operational. It is not a tour of every method. It is a proposed pairing. For the wider decision-making view, see AI-driven decision making in IT project management. For lifecycle frameworks that sit around a design like this, see AI-driven transformation in software project management.

How does the risk analysis component work?

The risk analysis component is designed to watch project signals, flag odd patterns, and predict issues with supervised models so a team can act while the sprint can still be saved. Anomaly detection handles the “this does not look like last week” cases. Supervised learning handles the “this pattern has failed before” cases. Together they aim at timely intervention, not a prettier register.

Anomaly detection is the unsupervised half. Velocity that collapses, a sudden pile of blocked tickets, or a test-fail spike can show up before anyone writes a risk note. The model does not need a label for every failure mode. It needs a sense of normal. That is also its weakness. A planned spike (a release week, a migration) can look like trouble. The paper's “timely intervention” line only works if someone can mark known exceptions so the system does not cry wolf.

Supervised learning is the labeled half. Past projects that slipped, overran, or lost a person mid-sprint become training rows. Features might include story size, skill mismatch, open defects, and load. The output is a probability that the current work is heading the same way. This is closer to classic predictive risk. It is only as good as the labels. If your history only records disasters that were large enough for a postmortem, you will miss the slow leaks.

The authors do not claim a published accuracy number in the abstract. That is appropriate for a proposal. If you build this, the first metric is lead time of the warning, not a fancy AUC. A model that is 90 percent accurate three days after the miss is a historian. A model that is 70 percent accurate two days before the miss is a tool.

How does NLP and reinforcement learning assign work?

The resource allocation component reads tickets with natural language processing and assigns them using reinforcement learning, with skill groups, workload, and performance patterns as the main inputs. The aim is automatic matching that does not overload the same few experts. A story about a payment API should land with people who have done that work, if they still have room.

NLP is there because software work is written in messy language. User stories, bug titles, and comments contain the real skill signal. A tag of “backend” is too coarse. A model that can see “OAuth refresh on the billing gateway” can match better than a dropdown. That also means the model will inherit the bias in your tickets: vague stories, hero culture, and modules that only one person ever touches. Cleaning the backlog is part of making the allocator honest.

Reinforcement learning is there because assignment is a repeated game. Each sprint is a new state: who is free, what is blocked, what burned people last time. An RL policy can try allocations, see cycle time and load balance, and keep the policies that finish work without frying the same three names. That is the theory. The reward function is the whole product. If you reward only throughput, the agent will feed work to the fastest people until they leave. If you reward balance and flow, it has a chance to be kind.

Automatic assignment will scare people, and it should until the reject path is real. A lead who cannot override a match will stop trusting the board. A junior who only ever gets leftover chores will stop growing. The paper's goal language (better decisions, fewer failed projects, higher productivity) only holds if growth and fairness are in the reward, or at least in the human review. Treat the agent as a dispatcher with a supervisor, not as a manager of record.

How would this sit inside Agile practice?

The system is meant to plug into existing Agile practice rather than replace standup, planning, or retro. Risk warnings should arrive in time to change the sprint plan. Assignments should land on the board the team already uses. If the tool needs a new ceremony, adoption will stall. The architecture is a full web-based stack with that integration as a design rule.

In planning, the allocator can propose owners as stories are refined. In daily work, anomaly alerts can sit next to the board so a slipping test suite is visible before the next planning session. In review, the same data can show whether the policy overloaded a person. None of that requires a new role. It does require that Jira, Git, and time data are readable. A model that cannot see the tracker is a side system, and side systems die.

Agile already has a human loop. That is an advantage. Scrum Masters and tech leads can treat model output as a third opinion in planning. They can also catch the cases the model will miss: a person returning from leave, a political stakeholder, a story that is small on paper and huge in production. The paper's “enhance decision-making efficiency” line is compatible with that. Efficiency is not the same as removing the conversation.

That table is a reading of the architecture, not a figure copied from the paper. Use it as a placement map. If a feature cannot attach to one of those four moments, it probably does not belong in the first release.

How should a team test this kind of system?

The authors outline three tests: benchmarking, simulation, and A/B testing. Benchmarking compares the model to current practice on historical work. Simulation tries futures the history does not contain. A/B testing puts two real teams, or two time windows, on different assignment and warning rules. You need all three. History alone is too kind to a model trained on that same history.

Benchmarking answers “would this have helped last quarter?” Pick a metric the business already believes: cycle time, escaped defects, sprint spillover, or people over a load cap. Run the risk scorer and the allocator on frozen boards. Compare to what humans did. If you cannot beat the human baseline on a metric that matters, stop. A nicer UI is not a result.

Simulation answers “what if the next quarter is weirder?” Drop a key person. Double the defect rate. Add a surprise compliance story. See whether the policy piles work on the remaining expert. Simulation is where reward-function bugs show up. It is cheaper than finding them in production.

A/B testing answers “do people actually use this?” A model that wins on a replay can still be ignored in standup. Randomize at team level if you can, or at sprint level if you cannot. Measure both delivery and human outcomes: overtime, reject rate of suggestions, and whether juniors get growth work. The paper's aims (fewer failed projects, more productivity) are incomplete without those human measures.

Velikov and Ivanova's contribution, as they state it, is the joined frame: risk and allocation as one architecture, built to sit in Agile, checked with more than a demo. That is a modest claim and a useful one. Most teams already have pieces of this. Few have a loop where a risk score can change who picks up the next story, and fewer still have a test plan for that loop. If you take one idea from the CompSysTech paper, take that. Unify the two problems, then prove the unification with a benchmark, a simulation, and a real A/B, in that order.

Frequently asked questions

What is intelligent software project management in this paper?

It is a proposed web-based framework that joins two jobs usually kept apart: predicting project trouble and assigning work. Risk analysis uses anomaly detection and supervised learning. Resource allocation uses natural language processing and reinforcement learning. The design is meant to sit inside Agile practice rather than replace it.

How does the risk analysis component work?

It watches project signals for unusual patterns and trains supervised models to anticipate issues before they become sprint blockers. The aim is timely intervention, not a thicker risk register. A person still decides what to do with a warning. The model is there so the warning arrives while there is still time to act.

How are tasks assigned in the resource component?

Tasks are matched to developer skill groups, current load, and past performance. Natural language processing reads tickets and stories. Reinforcement learning learns assignment policies that keep work moving without overloading the same few people. The authors present this as automatic assignment with those three inputs in view.

How would you test a system like this?

The paper outlines three checks: benchmarking against current practice, simulation of project scenarios, and A/B testing in live teams. That mix matters. A model that wins on a historical dump can still fail in a real standup. Simulation and A/B tests are how you find that gap before you roll the tool out to every squad.

Does this replace Scrum Masters or project managers?

No. The architecture is meant to reduce failed projects and raise productivity by making allocation and risk less dependent on gut feel and rigid rules. Someone still has to accept a reassignment, talk to a person who is overloaded, and own the sprint goal. The paper's contribution is a joined design, not an unmanned process.

Related articles

• AI-driven decision making in IT project management
• The role of AI in project management for software engineering
• AI-driven transformation in software project management