Tag Archives: Project Management

Team to Extreme

Week ago, I had privilege to be one of the speakers at Project World/Business Analyst World 2013 conference in Vancouver. It was advanced topic targeting mainly project managers, but others, who lead any type of teams hopefully benefited as well. During my presentation I introduced formula for team performance optimization, as well as I talked about factors that influence the performance and what we can be done to address them. Here are slides from my presentation.

 

Information management initiatives – who should be in charge after all?

In 2011 PMI and Forrester jointly published a report – “State of PMO”. Although the report was targeting specifically problems that Project Management Offices face, the interesting thing is that the findings are very much relevant to information management implementations. One of the measured factors in the study was the perception of value that PMO brings to organizations and its correlation to the organizational reporting lines. The surprising outcome of the report was that while organizations perceived the PMOs as of high value where they reported to CEO (38%) or CFO (36%), the approval rate dramatically dropped down when PMOs reported to CIO (22%) and VP IS/IT (15%).  This could lead to conclusion that the lines of business either:

  1. distrust IS/IT departments,
  2. perceive IS/IT as detached from the business and not addressing their real problems, or
  3. benefits from IT/IS initiatives are potentially intangible and/or never measured after projects are  completed

I do not have specific numbers for information management initiatives, but experience seems to confirm similar correlation. When information management projects are not driven by the business but rather by IT, they are often observed with distrust, little confidence and support. Indeed, some of the IT/IS information management initiatives focus on technology, with poor understanding of the business processes, goals and operations. If this is true, to improve the odds, they should be conceptualized and driven by the business groups rather than by IT.  Using Pareto principle, maybe 80% of focus should be on business transformation and knowledge management, and 20% on technology. Delivery should still reside within IS but the business should be firmly in the driver’s seat. The recent explosion in collaboration methods, are blurring the boundaries between the external and internal, business and social, stationary and mobile collaboration, bringing new opportunities and challenges. There is no doubt – the cloud computing is going to revolutionize the way how IS and IT departments work today. IT is becoming increasingly a commodity, and some jobs are quickly disappearing, although recent IDC study brought news that cloud services are going to generate 14 million new jobs by 2015. Too bad that they are going to be in some other, cheaper part of the world. This trend will also force redefinition of the role of the CIO – maybe putting ‘Information’ back into the title – changing the focus from the infrastructure and technology to identification, valuation, definition of metrics and the management of the information as any other enterprise asset. I believe that both – shifting of the responsibility for information management initiatives to the business, as well as recognizing that information is the asset will increase success rates of IM initiatives within organizations, leading to improved profits, reduced risks internally and better service to customers externally.

Information Management Context – Project Manager’s View

Implementation of information management projects is quite complex in ever changing business environments. The success or failure of such initiatives is often determined by ability of the project manager to see the big picture. Quite often such projects fail because the team concentrates on technology, neglecting other aspects of the environment. Technology is obviously important, but is merely part of the whole picture. Information management projects do not exist in isolation. There are many factors that need to be taken into account during planning, but also later closely monitored during the execution. The project manager needs to be alert to any changes in the environment and be ready to adopt. Rushing ahead with a project that do not addresses business need anymore, is going to lead to disaster.

What are the key elements of the environment that need to be addressed? The answer depends on the organization itself, but usually it could be grouped into following classes:

  • Business goals, principles and trade specific practices

Direction of the business, where it is going to be in 3 to 5 years, has direct impact on definition of business needs. The information management projects need to anticipate the change that is going to occur, and make sure that delivered business systems will support these needs, and there will be flexibility to adopt these systems easily when new requirements appear. For example, when implementing taxonomy, the project manager needs to make sure that it is scalable, so the organization will not have to spend fortune to redesign the system.  Buying trade specific classification from a third party, might save time, but each organization is different so this will require customization. Ability to satisfy business needs will also impact current and future end user satisfaction.

  • Organizational structure, roles and responsibilities of key stakeholders

Since every organization is different, it is not possible to use a single cookie-cutter approach. Identification of key players early in the project, and keeping them engaged during delivery is critical to success of the project. Making sure that stakeholders understand their accountabilities and responsibilities not only while the project is active, but also in the future when the delivered systems are operational, will help with establishing proper governance and change management.

  • Technology

Technology quite often introduces constraints to the project due to existing legacy systems, or decisions that were made already to standardize on specific products. However the project manager needs to anticipate change in the future in other systems generating data or consuming information. It is important that the project works closely with enterprise architects and monitor closely any other projects that are on the roadmap already. Quite often such projects introduce unexpected surprises, heavily impacting the project success. Even upgrades to existing systems might introduce need for change.

  • Corporate structure

Corporate structure changes quite frequently. Although information management systems should be independent from such structure by building taxonomy based primarily on business processes, often the corporate divisions have some independence in selection of tools and implementation of systems. Information management projects have often enterprise-wide effect, so making sure that all the involved groups are brought to the table, is extremely important. This is going to save lot of time and money in the future, when organization will try to leverage ability to mine information and knowledge.

  • Information Management practices

Depending on maturity of the organization, there might or might not be processes and practices in place already. The project manager must be aware of them before and during implementation. Also, delivery of new system has a rippling effect on overall ability to grow in such maturity, impacting governance and change management.

 

In summary, project managers implementing information management projects need to be acutely aware of the complexities of the whole environment, not only focusing narrowly on deliverables. Ultimately success of the project is not only measured by being on time, within budget and scope, but primarily by acceptance and usage after the project is delivered.

Managing Risks in Information Management Programs

Information Management projects belong to most challenging in my opinion. One of the reasons is the degree of uncertainty related to current state of data, and usually duration of the program. Although there are discrete steps within ECM programs that are handled by specific projects, overall duration of the initiative is pretty long. This makes such initiatives sensitive to changing environment, political landscape changes within organization, changing external laws and regulations and so on.

Managing risks is key factor in achieving success in the program. Risks must be managed constantly, maybe not weekly, but definitely should be reviewed at least monthly. In my current organization we set up monthly Risk Review Board consisting of individuals representing various aspects of ECM program – including  business analysis, technology, architecture, change management and governance. During our meetings we focus on new risks that appear, prioritization and working out mitigation plans for 20% of them (according to Pareto law – 80% of biggest threats comes from 20% of risks). Risks are assigned to owners who need to manage them, and report back on their status.

We have to be transparent to the stakeholders communicating the biggest risks, although this needs to be done in a way that takes into account their level of tolerance. We do not want to create panic when it is not necessary. This is the point where program manager’s experience comes into play. If we are confident that we can handle these, we should provide brief statement about the risks showing confidence in handling them. Only risks that are outside of program manager’s influence,  requiring stakeholders stepping in to mitigate them, should be worked out in detail.  After all, this is similar to flying a plane. It is sufficient for the captain to say to passengers to fasten belts due to entering into turbulence area,  rather than getting into details that the autopilot has just stopped working.

Chaos or Agile?

Recently I have had conversation with a project manager claiming that he was running project in an ‘agile’ way. The project is performing poorly with constantly missed deadlines, missed deliverables, and poor quality. This response came when I asked for project plan. Well – there is one but it doesn’t reflect what happened or what is currently going on with this project.

Although I am all for using Agile approach, especially in enterprise content management and records management projects, but Agile is not synonymous to Chaos. Obviously this project manager is using word ‘agile’ to create smoke screen and hide what is really going on behind the scenes, but I noticed that this is becoming a common trend among project managers nowadays. The problem is that ‘agile’ became a buzzword for organizations that are in quest of finding a magic solution to their chronic delivery problems. Agile will work, but only in mature organizations with mature teams, but it could make things worse in organizations that still lack of foundations of good delivery.

In the strong, prescribed methodologies it was easier to spot when things were going wrong, so it was easier to remediate. Obviously they went wrong from the very beginning, starting with development of rigid requirements that often did not address what the end client wanted. The requirements became substitute for communication with the end users, so end result was often not what the client was expecting, and the biggest enemy became word ‘the change request’.

Agile still needs to have a plan, however a plan that adopts to changing environment, business needs and dynamics within project team itself. There must be controls in place to identify when project is getting off track. These controls are different than in traditional world. This difference is related to different approach. In traditional world the problem was handed over from the business to technical team to deliver solution. The ‘agile’ way is not to have distinction between business and technology – it is only one team delivering solution, consisting of business and technical people. There is no more shifting of the accountabilities and responsibilities between the two. There is a team resolving business problem. This leads to shift in way how the projects are measured. The shift is from the project centric reliance on how the project is doing in terms of the triple constraints, to delivery of business value and tangible results and this is how the projects should be measured. The budget and time are still important and fundamental to the project, but the focus should be on delivery of business value.

This is the point where project management becomes more art than science – balancing act between rigid approach and the chaos on the other side. But Agile is not synonymous with Chaos.

Do you have budget for ECM intiatives?

If you are like most of us – I am sure you are facing the same problem – there is not enough money to implement full Enterprise Content Management program. Programs like this, require substantial amount of money, multi-year commitment, strong executive sponsorship and so on. Even if there is some money allocated to some of ECM initiative, the fact that duration is usually longer then 12 months alone make such initiatives vulnerable to changing fiscal environment within the organization and external markets.

Recent Garter’s research among CIOs found out that organizations will be spending less on IT initiatives through 2015. This means rationalization of IT assets, delivery efficiency improvements,  and business process optimization. When you think about this – lot of these initiatives could be supported by decent information management, however it is not clearly visible and most of IT managers, CIOs and CFOs look for hard benefits.

So what could be done to continue with information management projects in such uncertain times? One is obvious – develop information management strategy and roadmap, and then constantly build support and sell new IM projects. The other – ‘guerrilla approach’ is to push information management foundational initiatives as part of other projects – even if their primarily goal is not directly related to information management. For example – to deliver Enterprise Information Architecture – look for current projects that need to develop such piece as part of the project. By influencing – some of these initiatives could be expanded to include informational assets scans in particular business area, existing information management processes, metadata, procedures and so on. Gathering these together could become beginning of EIA and help with developing of governance. To be successful with this however, there should be a group of people driving this, and which has some visibility and influence over the existing projects. In larger organizations – perfectly suitable is IT Architecture group. Most of the projects require their services, and they could influence the scope of the projects. Obviously it requires lot of sensitivity and balance to execute properly, and architects must be sold on the concept.

The Mythical Product Owner

(This article was originally published on Pragmatic Marketing.com)

Product Managers must quickly adapt to the Agile methodology, or face becoming sidelined. It is critical to understand the relationship between traditional and new roles within a delivery organization, particularly between the Product Manager and the Product Owner. By Andre Kaminski

Background

Barbara Nelson said in The Politics of Agile, “When product managers weren’t looking, the developers went agile.” Indeed, many Product Managers were taken by surprise at the speed of Agile’s adoption. And with the introduction of a new Product Owner role and its perceived overlap with the traditional Product Manager function, Product Managers have expressed some anxiety about the future of their role.

Agile was borne from frustrated development teams who were constantly blamed for non-delivery and missed business goals. Nothing in life is black and white, and objectively speaking, problems could be found on both sides. Nevertheless, Agile was a response from tactical teams that wanted to control the rules of the game and redefine the criteria for success.

Since the Agile process was created by tactical teams, it concentrates on development practices. At times, Agile may seem inattentive to the environment in which projects are delivered, and to hold idealistic views of reality. However, Agile has many merits, and for organizations to be fully successful, the changes of Agile need to happen not only on the tactical level of delivery, but across the whole organization. It is not enough to have a fully functional and efficient development team that delivers, if it does not translate into success of the company. As product managers, we bear the responsibility for bridging the two worlds – technical and business, and need to influence both. Ultimately, we are responsible for the success of the product and, thus, the company. We cannot point fingers anymore and say, “It was the developers who did not deliver,” or, “It was the business unit that did not have a coherent strategy.” Although there may be some truth to these statements, the art of product management is to influence strategies and plans even if we do not have direct authority over them.

Change must happen on two levels across the organization:

  • Technical – Roles and responsibilities must be understood, accepted, and adopted.
  • Cultural – Attitudes, expectations, political ambitions, and how we collaborate must change.

Obviously, Agile should not be introduced with a ‘big-bang’ approach. Instead, by demonstrating that the new process works on a tactical level, and building confidence within the organization, we can show the way forward for the rest.

In this article I concentrate on the role of the Product Owner. This role is critical to the success of any initiative, and yet it is not widely understood. For tactical teams, the Product Owner represents the business, yet there is no clear definition of who that person should be. Articles or books by technical Agile authors almost always present the Product Owner as a jack of all trades—whatever information a team needs, the Product Owner delivers. Posts on the website of Scrum Alliance (the professional organization of Scrum practitioners) call for more training of Product Owners so they understand what it means to be ‘good’ Product Owners. Clearly they are not getting what they need from this role.

Since Scrum describes what this role should do, but does not say who specifically from the traditional world should play this role, Product Managers are put in an ambiguous position. According to Scrum, the Product Owner can be anybody – the Business Manager, an internal or external client, or the Product Manager—as long as this person is part of the team and can devote enough time to the role. The simplistic assumption is that the Product Owner contributes to the success of the company by performing whatever business-side functions are possible. This assumption may be true as long as this person sees the big picture, understands the market or client problems, sees the market opportunities and trends, and is able to quantify them. In other words, the expectation is that the Product Owner is, at least partly, also the Product Manager, regardless of title.

So there is overlap between what teams expect from the Product Owner and the traditional role of Product Manager, but is this the same person?

Read more »