Let us imagine the situation. You implement BPMS in your IT architecture. But the implementer keeps pushing back the deadlines for the final deployment, and the business processes that were supposed to start at the MVP stage are executed incorrectly.

What to do in this situation: “finish” the project with the current team, change the project executor, look for mistakes on your side? Will any of these solutions aggravate the situation?

We do IT development on request, and we often receive requests to continue a project from other IT companies. During the time we have worked on such projects, we have learned that we should not get excited about such requests: often there are systemic problems in project management which the contractor is unable to solve alone.

In the most simplified form, outsourcing in IT is built approximately according to the following scheme: setting a task – re-setting the task – execution. The client, in the person of his manager or project team, assigns tasks to the contractor. The contractor, again through his manager or project team, processes these tasks, analyzes the requirements, formulates an action plan for his specialists.

A problem can arise at any part of this chain. Let us consider each of them in more detail.
Problems in task formulation

There is a problem with the culture of project management in development. IT processes cannot be managed in the same way as, say, a warehouse or a factory – you need completely different methodologies.

For example, there are the following four types of systems:

Streamlined simple – the result is clear and predictable, there are already examples of successful practices to achieve it, the input conditions and requirements for the result do not change. For example, the task “to build a house” is clear and measurable, it does not raise questions for specialists.

Complex – the task is not unique, the desired result is approximately clear, but the best practices in solving similar problems have not yet emerged. The task “to build a city in a swamp” is solved with the help of successful practices in construction, supplemented by common sense and engineering thought.

Confusing – the system has increased uncertainty, the result is affected by changing factors and risks that must be responded to. The understanding of the ideal outcome changes with these factors. Now the team has to build a city on the surface of Mars, optimize its delivery cost, work out life support systems, compensate for possible risks and system failures.

Chaotic – there is no understanding of either the outcome or the best practices to achieve it. Conditions and priorities are constantly changing. Management and the team react to them ad hoc. The task in the example gets complicated to “build a universal dwelling module, which could be “deployed” on the surface of any planet – a gas giant, a planet with a high temperature, an Earth-type planet. No one has yet solved such a problem, so it is unclear what materials, technologies, shapes, etc. would be optimal.

Each system has its own peculiarities, each requires a different approach. If the wrong management format is chosen, the project can simply fall apart.

What is a problem statement in IT? When there is a task to paint the walls, there are no risks. When there is a task to deliver goods, the process is also largely predictable. In IT the implementation of something is the beginning of figuring out how it should be done.

You can, of course, try to manage a messy environment like a complex one – by preparing terms of reference and everything else (see Cynefin framework, Toyota Tao, Agile Manifesto, etc.). But we’ve never seen a single terms of reference in our lives that matched the final implementation, nor have we seen a single agreed-upon design layout that wasn’t adjusted during implementation.

And since we’re dealing with a convoluted system where specific jobs will be constantly changing and refining, we should have project goals and their measurable metrics agreed upon with all team members – this will ensure that we don’t lose focus.

If you’re managing a project as a complex project, the team doesn’t know the goals and metrics and only sees the tasks you set. A lot of business analysts have already worked on the task at the time you set it, a lot of time has been spent on pointless discussions about project architecture (it is useful to discuss project architecture, but bureaucracy should not be a priority).

The post Changing IT Contractors appeared first on IT-M Learning.

Remote work presents new challenges. Contractors are far from the customer, now you can not look them inquisitively in the eyes to assess how much they themselves believe in the named deadlines. Weekly phone calls, our favorite management tool, do not give us a feeling of sufficient control. And there is no assurance that deadlines will be met. First, every week, the project manager cheerfully reports that everything is going according to plan, and then suddenly without a declaration of war it turns out that the deadline has already been broken.

An experienced customer, of course, is able to suspect something wrong at an earlier stage, based on body language and uncertainty of speech of the manager, but for this you need personal contact. So what to do? Let’s rack our brains together.

My order, my rules.

The one who pays is the one who makes the rules. So let’s not be lazy to set them. It is quite reasonable to inform all participants, that the customer will adequately perceive and perhaps even encourage for the timely warning of possible deadlines and other problems. Justified, of course, by some signals and changes inside or outside the project, even if intuitively.

It is quite logical to explain to all project participants that advance warning will allow risk management, to take corrective actions. And most importantly, it puts all project participants on the same side of the barricades: “all together against the problem,” rather than “customer against performers trying to justify failure to meet deadlines.

On the contrary, draconian sanctions can be imposed for failure to meet deadlines and the onset of problems without early warning. If they tried to prevent the failure, but could not, it happens. But if you didn’t even try because you didn’t know and didn’t anticipate, that’s a shame.

Operational Metrics.

Ours is an age that demands ever more rapid reactions, more rapid management decisions. Our age demands more and more rapid response, more rapid management decisions. Monitoring the progress of a project at weekly meetings is already too infrequent. But it is also impossible to spend a lot of time. So, we need some indicators, simple but eloquent indicators that give signals on time. Reducing the project buffer, if you are a Goldratt fan, or a trivial combustion chart will allow you to keep your hand on the pulse.

Better yet, set up a “red light” that will light up when the metric deviates from the design metric, prompting the customer and the project team to react in a hurry.

What’s next

And then the main thing is not to stop. Rigidly fixed rules and indicators eventually cease to work. This means that at the end of each incident, problem or even just an undesirable phenomenon it is necessary to adjust the rules, supplement the indicators and look for other solutions.

And also – do not lie to yourself. By admitting our mistakes, we give ourselves a chance to correct them. As long as we are wrong and correct, we are not only living, but also developing.

The post How to control IT projects appeared first on IT-M Learning.

1. Agile “rules

Flexibility comes to the forefront both in relation to a single project and to the project portfolio as a whole. Multi-level project plans with grandiose Gantt charts, multi-page documentation, budget-timeline-subject area constraints make projects sluggish barges, whereas fast and maneuverable boats are required.

What needs to be done.

Analyze the business benefits of the project. Answer the questions: can the planned business benefits be achieved in the current environment? How much can they be reduced? How can the project be reformatted to remain cost effective?

Determine the possible losses from exiting the project and relate them to the possible business benefits.

Calculate different possible scenarios for project implementation, revise the subject area.

Re-evaluate the components of project portfolios-projects and programs-with this analysis in mind, and re-prioritize components. Remember that not only projects, but project portfolios should be flexible.

For projects where it’s impossible to switch to Agile methodologies, use hybrid approaches or some useful Agile tools, such as a Kanban board, open-ended questionnaires, daily meetings of project teams (although in an online format), planning poker.

2. being agile means making decisions quickly

In the hierarchy of a particular organization, the project office, portfolio, program, and project managers may not have direct access to the company’s top executives. The managerial weight of the project manager is on average lower than the managerial weight of the functional managers. Therefore, decisions related to project activities are made slowly and are not always justified. It is necessary to speed up the project decision-making cycle.

3. The crisis project manager is a communicator and motivator with good technical intelligence

In a crisis, especially when working remotely, the project manager’s competences in team management and technical intelligence, i.e., knowledge of modern information technologies, are of primary importance. If you remember the phases of team development according to the “Tuckman ladder,” the current situation has put many project teams in the storm phase. Management models through large-scale meetings with a large number of participants do not work in these conditions. First, decisions must be made quickly, and second, project team members must constantly feel engaged and motivated to work so they don’t lose momentum. Instead of long meetings, it is better to hold brief analogues of daily standups, to use methods of collective decision-making. The project manager should pay special attention to employees with low personal motivation, find time for daily contacts with them, and constantly “keep his hand on the pulse.

4. the traditional project office must change

Traditional offices are aimed primarily at the successful implementation of projects by spreading project methodology throughout the company, monitoring the performance of individual projects and the portfolio as a whole, providing interaction with the project teams of third-party performers. The understanding of project success in this case is also traditional: within the previously defined budget, terms and subject area. The motivation systems for project office staff and project managers are most often “tied” to these indicators. As a result, traditional project offices are not very interested in changes, especially significant ones, they are not ready to work in a situation of uncertainty, when you need to make decisions quickly and take responsibility. At the same time, when project offices work remotely, the burden of organizing communications between project teams and stakeholders falls on the project office staff. Activities need to be organized in such a way that project teams are given effective tools for interaction and are not left out of the field of control.

5. Automation becomes a means of survival

Flexible approaches in project and portfolio management do not mean uncontrollability. The needs of company management for information on project activities in times of crisis increase manifold. The use of “zoos” of information systems (IS) by different project teams, leaving the control zone due to remote work, the absence of a single system that accumulates all the information about the project activities make the preparation and provision of such information problematic. That is why it is high time to think about the creation of a corporate project management information system.

The post Changes in project management: how to meet the new challenges appeared first on IT-M Learning.