A short reflection on XPM and Scrum

I had a recent talk with one of my colleagues – an academic one and we collected some ideas during our talk about the comparision between the Flexible Project Model(XPM that is) with the Scrum development framework noting similarities and differences and which one may work for the reality…

The Flexible model has a number of similarities with the Scrum Development Cycle. There is a meeting before the development period – essentially to pick up what will be done in the production cycle. Product grooming seems to be done in the initial period in flexible project model. This very much like the sprint planning session in the scrum methodology. Use of time boxing is a common denominator in both concepts. Also the notion of planning of the next development cycle is also present in all cases. Strictness of the time boxing itself is also a common denominator in my opinion as dictated by some sources I came across on the web.

These can be summarized really, into the following points:

#Both models bring a competitive approach to the project mangement process. This is importan since market changes faster and only the companies which are flexible and can react fast stay competitive.

#Both models Scrum allows the incremental and controlled development. Controlled is the keyword here.

#Both models bring confidence in the system through transparency of the processes. All the stakeholders are informed where the project is and this is a good thing for their dedication and commitment.

#They produce quality at every step. Testing is an integrative component of Scrum and XPM at every iteration whatever it is called.

#Both help to foresee risks and employ systematic risk management. Be it timeboxed or sprint regular releases, they establish the ground to recognize problems early and react promptly.

Some differences do exist however with the Scrum model; like the people who attend the meetings are defined differently to start with in the flexible model. Also, things like planning the current development cycle and recommendations about about process is time boxed in the flexible model whereas these are not time boxed in the scrum model.

These differences however subtle and in my opinion Flexible model is essential and approximation of the Scrum model for a wider perspective. Actually, I may go out boldly ( and in blissfull ignorance ) that the flexible model is actually better suited to reality than the scrum.

Posted in agile, Product Life Cycle, Unsorted | Leave a comment

Selecting the best match for your project subcontractor

It is probably one of the most important and at the same time time consuming tasks
– selecting the right subcontractor for my project’s requirements. Generally choosing the wrong subcontractor dooms the project if not making things utterly intolerable. The PM must get it right and to build a strong partnership with the subcontractors.

I think the following points can be brought forward as factors to consider for choosing the right one ( or at least coming close )

The “Experience” – did they do it before or will you serve as their kindergarten experience – Yes, The “Experience” is an important factor. You can rely on experience – a subcontractor that has extensive experience within its team and with what they produce will almost certainly deliver. However, with the reverse of the situation they may have a poorer understanding of what is needed and they may actually gain that experience using your money and time – something which you dont want.

The “can do” factor – Ability  – IMHO, this is probably the first and foremost important factor in choosing the right subcontractor. You have to asses their capabilities and ask if they have the right mix of resources, expertise and equipment that is required to give us what we need – at the our desired quality standard , within the budget and finally on time.

Finally there is the compliance aspect – We have make sure that the products delivered by our subcontractor will be of high quality – consistently. That is why we have standarts and there are a number of of them to help ensure this. PM should always check with the subcontractor to confirm they have the right certification and compliance.

Posted in Unsorted | Leave a comment

How to manage that risk in your project…

It is a given that Risk and uncertainty are natural component of the project work. Let’s not fall into our own illusion – if they are not managed properly in any project – especially a large ICT one – we will certainly run into trouble.

However, there are ways a good project manager can mitigate and manage risks. It follows that if a team has a well prepared risk management process installed, then it will be possible to identify and deal with all the project’s risks in the right way. If risk can be managed well, fewer issues will come up and that project team will be prepared for all possibilities with a reasonable amount of happening.

We believe that we can manage the risks that may affect us by following the steps described below:

Immediately on day 0 – go and create a risk register for your project in a spreadsheet format and populate it with all hypothesized current risks on your project getting input from all of the the project’s key team members and stakeholders. At this stage  it is essential to cycle through all the inputs that are important to complete the project and if possible go and ask each stakeholder ( seriously, I mean every one of them )  if they have any concerns or if they see any potential problems.  Essentially, we need to identify risks that are related to our requirements, technology, materials, budget, development resources , quality, suppliers, regulative and legislative issues etc.

It also goes without saying that once we start to identify the risks, we also do need to balance the corresponding side in positive risks and opportunities. A good way to do this is to include all possibilities that in a way that could affect our project positively. What if too many subcribers turned up to join our streaming service etc ? Be ready to capitalize  on this opportunity and plan for it in any way possible. Plan for problems but be prepared for a time when opportunity knocks.

It is equally important to establish how likely a risk is to occur on a scale and then determine the impact of each risk according to a number of factors such as quality of work delivered, project cost and time. Then we will focus our attention on those with the highest potential impact and likelihood of happening . After this we need to identify what can be done to lower the likelihood and impact of each one. A fishbone analysis may be the best way to get to the root cause by asking why and how – the root cause analysis. Next step will be to estimate how much it will cost the IXIR team for that risk’s impact and then add the cost of the risk response to our overall estimate as a contingency cost.

A good way I learned from my own experiences is that – it is essential to assign an owner to each risk and never leave a risk factor unattended. Have each angle covered … No exceptions otherwise the blame game will be on immediately after the first wave hits. Make sure that the person you choose is the one who is most suited to deal with this particular risk and who can monitor it.

Finally, like with the project cost management, a risk management plan must be a living thing and cant stay dormant. For this reason  have your stakeholders to attend regular meetings at specific intervals to identify new risks and to monitor the registered items.

Posted in Unsorted | Leave a comment

The Do’s and Dont’s of making sure your project budget is both accurate and complete.

Developing and maintaining an accurate and complete project budget is probably one of the most important things for a PM since the project budget is the total final expected financial cost to finish a project during a specificly defined period of time, with a very specific and well defined result.

Project budget helps us to track the budgeted versus actual cost which is yet another indicator of our success or failure. It is an early warning indicator. Budget provides us a screen that lets us know in the end, or all along the way, how we do actually.

To achieve accuracy several factors should be included in this process:
include the direct cost, directly related to the project, as well as any indirect cost as well.
include fixed and variable cost, any labor and materials as well as travel.
Include intangibles – like may be some travel related expenses we need to include, as well as equipment we may need and any space, any leases or license costs.

To achieve the accuracy of the budget there are several things that can be considered during the creation and maintenance of the budget.

First of all, it is a very good idea to use historical data given that it exists. We may actually have executed a similar project in the past, then it will be good time to use that historical data so we can compare data, and by this way we won’t have to start from scratch or estimate without a base line.

It is possible to use a number of methods to estimate our figures but generally the following methods are used :

+ Bottom Up Estimating: We start with the minimum viable components in the plan and then add them up

+Expert Judgement: Ask your experts ( in/extra team) to work out the cost of a task

+ Analogous Estimating: We can make use of the past experience in the team or outside to decide how much the project tasks will cost in our case.

I think those following 2 points deserve more explanation : they make use of BI that we possess currently:

In the spirit of AGILE framework is that we use the lessons learned for the project. We can import not only the data from past experiences but lessons as well. No one really wants to repeat the same lessons – it is a very expensive process. We can take those and include it in the current one also. While doing this – we must make sure that we are using all our resources – ie leveraging our matter experts that include your team members. Anyone on our team, who possibly have done similar stuff, can provide input, or any stakeholders.

The next point is to confirm the accuracy of the data we use. Never forget the maxim , garbage in / garbage out. Our project budget should be held to scrutiny once drafted, a good ideas is to have people look at it to ensure that data is accurate.

As we underlined before the project budget is about monitoring . So – we must also baseline once the above points are met.That’s what we will use for the entirety of the project to see the variance. There will certainly be changes on the way, and we have to be able re-baseline along the way. This will give us immense flexibility.

Finally, immediate and precise updates to the budget are the key ! An obsolete or  un-updated budget is worthless. We need to update the budget real time. There can be no flexibility on that. If there are changes to the budget, it has to be recorded on a regular and consistent pattern so we are looking at the the right numbers.

Also, a little tip to mention is that related to the above principle is that to get things back on track as soon as possible because every little deviation from the budget and reality will just make the problem worse. You can’t work on two different realities – the one belonging to the real life will dominate the other one everytime there is a conflict between two.

Posted in Unsorted | Leave a comment

More on that risk thing…

It deserves mentioning that Formal Risk Management is tasked with some essential tasks if it is needed to help – it must identify risks and has to come up with strategies to guard against these risks. Additionally, to execute these strategies, and to motivate all stake holders in the project to cooperate in these strategies, it has to implement a corresponding Risk Management Plan.

It goes without saying that in the larger scaled projects we generally and naturally face more risks, so our risk management strategies also need to be more sophisticated and geared up to the task. Similarly, the risk management process ( the people who execute it ) is responsible for assessing each risk and determining which of them are critical for the project. The critical risks would then be those that can possible have a negative impact on the project and would then be prioritized.

Essentially, the whole goal of risk management in a project is to make sure that the stakeholders only take the risks that will help the project achieve its primary objectives while keeping all other risks under control and keeping their options open and B-Plans ready should those pass from probability phase to reality phase.

Posted in Unsorted | Leave a comment

Playing Risk! …not the board game.

It goes without saying that  risk is probably the main cause of uncertainty in any project. Risks can not be ignored if we really mean attaining a successful outcome for our project. I believe good PMs are focused more on identifying risks and managing them before they affect the business – which is actually the basic definition of a formalized and balanced risk management. The reason behind this is simple and it is mandatory that we implement it – the ability to manage risk will help us to act with confidence on our decisions with the project and help us to steer away from problematic areas and when we hit one of those risks we will be able to recover much much faster.

Simply, formal risk management will give us executable options on how to deal with potential problems – and certainly a peace of mind
Without a formal risk management methodology a project manager cannot possibly define project objectives for the future reliably and it follows that if those objectives and the related tasks are planned without actually taking the risks into consideration (ie without a risk management plan), chances are that the project will certainly veer away from its planned target once any of these risks hit materialize.

Posted in Unsorted | Leave a comment


Transparency was hard to achieve in a big company, especially in one that is owned by several huuuuge[Imagine Villanele from Killing Eve saying this]  shareholders who have their own agenda. 

However, if you achieve it transparency leads to better employee relationships – up/down and across the horizontal. We all know that people don’t quit just their jobs, they also – and probably just as often-  quit their superiors/bosses/managers and so-called “natural leaders”. This was one of the issues where I worked in. While I can proudly boast that my own team’s turnover was way way low to the company wide average , I saw a lot of good men and women simply excuse themselves out of their really decent positions because they found it hard to do their best for objectives no one bothered to explain to them. I know you can’t be totally open in a company but one way or another you do have to manage this open management and transparent coordination concept if you want your A-team/Fire Brigade Regiment to stay with you until the bitter end.

I always underlined to my people that when it comes to developing good workplace relationships, trust is front and center.  This was part of my “Manifesto” that I dicated to every person I worked with in my team. I saw that when leaders are transparent about themselves in a project setting, problems are solved faster. Take Capt. Miller in Saving Private Ryan, explain why we are here and what we are asked to do but keep some for yourself ( and never ever gripe down to your team members, they dont really like that, you always gripe up). I know I am stating the obvious but let me itereate that by being open and honest about project’s problems, project members will really help to find solutions, together. Now everyone says that, but just how many do that ?

Posted in Unsorted | Leave a comment