Archive for the ‘Integration’ Category

Measuring Your Agility-KPI Ideas

The technology and solution providers has been in this quest and journey of helping or making enterprises become agile. Most of the conversations I have had with management teams will always bring up a topic to a certain degree that refers to being agile or become more agile. Just like the words innovation and DevOps, the word agility is a loaded terminology. Every organization will look at this differently based on its organizational or enterprise context. Speed of delivery has always been something that management or the executive team wants to have due to market and economic conditions. The challenge is how does one implement agility in an enterprise and not just the I.T. organization.

The usual approach is to start with I.T. particularly when building a technology solution; software and/or infrastructure. However, starting with I.T. does not always mean that agile adoption or agile transformation will work and add value to the organization. It is all about the adoption and transformation context. Most of the time the agile transformation or adoption is challenged if not completely failing. There was even an article written here in LinkedIn titled “Agile does NOT work!“. I agree with some of the frustrations written in the article. However, this tells me that the people particularly the management/leadership did not really support the initiative to make sure it works and adds value to the enterprise. I always say this to anyone I speak with. When you choose to take the path into enterprise agility, you don’t just do cowboy coding. You don’t forget the practices that makes a product fit for use and fit for purpose. The trouble most of the time is that the people almost always fall into the trap of “just doing it”. Product release (software or otherwise) should always be based on the principles of fit for use and fit for purpose that is delivered faster to meet business and market demand. Adrian Wible wrote some sample considerations when working towards enterprise agility. Below is his sample list :

  • Legacy system dependencies
  • Vendor dependencies
  • Disparate technologies requiring different skill sets, resulting in divided teams—e.g., mainframe versus Java, mobile versus web
  • Geographical separation of talent (different time zones, or even just different floors)
  • Coordination among software, firmware, and hardware teams
  • Lack of automated tests (I think this is one important key constraint in achieving agility).

Adrian further talked about potential agile maturity performance indicators to consider when transforming into an agile enterprise or at the minimum an agile I.T. They are as follows:

  1. Agile requirements maturity. What to build.
  2. Engineering practice maturity. How to build.
  3. Testing practice maturity. How and what to validate.
  4. Deployment maturity. How to release.

I thought some of the contents in his article would help the reader take a step back and re-consider the approach they are taking towards enterprise agility.

What’s your thought?



Project planning with complete activity sequencing is about having a dashboard for early warning of risks and problems that provides the PM the ability to execute proactive management corrective action.  There is value to project planning and an important part of the project management plan.

This is not an easy task if your team does not see value to it and if they see it as a means to reveal weakness.  One of the duties of project managers is to educate every project team they work with on the value of the project plan.  You will face questions or you will be challenged when sometimes you report the status of the project based on this and the team will say you are wrong.  I always say that my report from the project plan comes from their progress report input.  The data the team provides give the picture of where the project is and you will be able to accurately say where the project stands minus the guessing.


The community of project management is currently teeming with “practitioners”, consultants, PMI volunteers and onlookers.  You have heard numerous times managers speak about using project management as a tool to help them achieve their goals.   However, one would wonder why different organizations continue to have different interpretations of what project management is.

Some organizations give a title of a project manager to a staff and use him/her as a procurement agent.  Some organizations expect the project manager to be an admin assistant to someone higher doing clerical work.  Some organizations will expect their project managers to simply agree with their superiors and not say no even when they don’t agree.  Otherwise, they are looking at walking out the door sometime soon.

What is really causing this trend?  Is it the lack of understanding by many organizations?  Is it due to fear of losing control that management is not willing to really use the project managers as they should be?  The project management community should probably address this and find out how we can get better in the practice of project management.  We have always promoted the best practices but when we hit the ground running, we almost always forget the correct way of executing the work of a project management professional.

I would ask the community and may be PMI to champion the cause of project managers and continue to help elevate them as strategic resource in any organization.

I would welcome all your comments.