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.
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:
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.
Any successful information management solution implementation requires establishing of a proper IM framework. Such framework will help with forming governance, setting up priorities, definition of constraints, and will give the overall direction to any future information programs.
The foundation of such framework is based on existing legal, statutory and regulatory requirements. Establishing of such basis, especially in larger organizations is not an easy task and requires involvement of several parties. I made an attempt to capture some of these laws, standards and regulations used in the US and in Canada. This list is far from being exhaustive; every organization – depending on type of business – will have to establish their own baseline, which will include specific industry regulations.
United States:
| Law, Statute, Regulation | Short Description |
| Sarbanes-Oxley (SOX) 404 and 409 – Corporate and Auditing Accountability and Responsibility Act | SOX deals with monitoring of creation and management of financial records, as well as disclosing of information about changes in the financial conditions or operations of the organization. It affects primarily publicly traded companies including accounting and security firms, auditors and brokers. |
| Health Insurance Portability and Accountability Act (HIPAA). | HIPAA refers to protection of individually identifiable health information. It enforces that organizations handling such personal information notify the patients about their privacy policies.Organizations affected by this policy include health plans and health care providers. |
| Children’s Online Privacy Protection Act (COPPA) | COPPA requires that online content providers, working with audiences that include children must use reasonable procedures to ensure that child’s parent is included in the process. |
| Department of Defense 5015.2 (DoD 5015.2) | DOD 5015.2 identifies requirements based on operational, legal and legislative needs that records management solutions vendors must fulfill. It affects software vendors of electronic document and records management systems. Several government offices in the US require compliance with this standard, but also some other, larger organizations implementing information management systems, often use this standard during selection process. For this purpose, this standard is often used outside of the US. |
| Securities Exchange Act (Sec Rule 171-3 and 17a-4) | SEC act outlines requirements for data retention, classification, and accessibility for organizations involved in financial securities trade. |
| Gramm-Leach Bliley Act | The act is regulating handling and sharing of personal information, and disclosing of privacy policy to consumers. It primarily affects financial services organizations. |
| IRS Rev. Proc. 97-22 | This guideline includes directives for taxpayers on maintenance of financial books and records using software applications. |
| Electronic Signatures in Global and National Commerce Act (ESIGN) | This act regulates use of electronic records and signatures in commercial transactions. |
| Fair and Accurate Credit Transactions Act (FACTA) | It allows consumers to request and obtain free credit report every 12 months. It also contains provisions to reduce identity theft and secure disposal of consumer information. The financial institutions are mainly affected by this act. |
| Fair Credit Reporting Act (FCRA) | FCRA regulates the collection, distribution, and use of consumer information, including credit information. It affects consumer credit reporting organizations. |
| Freedom of Information Act (FOIA) | It guarantees access to the full or partial previously unreleased information and documents controlled by the US government. |
| Government Paperwork Elimination Act (GPEA) | This act requires federal agencies, where practicable, to use electronic forms, filing and signatures to conduct official business. |
| Occupational Safety and Health Act (OSHA) | OSHA governs occupational health and safety in the private sector and federal government. |
| Uniform Electronic Transactions Act (UETA) | The purpose of this act is to integrate the differing State laws in matter of retention of paper records, and the validity of electronic signatures. It supports the validity of electronic contracts. |
Canada:
| Law, Statute, Regulation | Short Description |
| Personal Information Protection and Electronic Documents Act (PIPEDA) | It governs how the private companies collect, use and disclose personal information in the course of conducting business. |
| Secure Electronic Signature Regulations (SOR/2005-30) | These regulations stipulate how digital signatures are created and verified. It is related to Canada’s Evidence Act dealing with integrity and validity of electronic documents. |
| Access to Information Act | Regulates access to the full or partial previously unreleased information and documents controlled by the Canadian government. |
| Privacy Act | This act stipulates rules how the federal government must deal with personal information. |
| Limitations Act | Limitations Act defines period of time during which legal proceedings maybe initiated, and thus influencing definitions of retention periods. |
| Ontario Bill 198 | It provides regulations of securities issued in the province of Ontario. It roughly corresponds to Sarbanes-Oxley in the US. |
| Microfilm and Electronic Images as Documentary Evidence Standard | This standard deals with microfilming and electronic image capture. It also describes process of establishing a program helping with ensuring document integrity, reliability and authenticity. |
| Electronic Records as Documentary Evidence Standard | This standard delivers provisions to ensure that electronic information is trustworthy, reliable and authentic. |
It is important to remember that the process of establishing such baseline requires deep involvement of legal department, and several business subject matter experts. Since the laws and regulations change from time to time, the organization should appoint a steward responsible for maintenance of the framework, and establish a governance model describing what to do, when such laws or regulations change.
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:
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.
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 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 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.
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.
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.
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.
As Peter Drucker wrote – knowledge is about increasing capability of individuals to do something different or being able to do something more effectively. Knowledge is not limited to individuals, it also exist on organization level. However this is the area where it becomes more esoteric. Although there are different models trying to define and put knowledge into some kind of a structure – I do not think that anybody got it right so far. There are many reasons for this although I think that it is primarily related to complexity of individual mind, and at the same time influences of human interactions as well as factor introduced by environment or context. It exists not only in physical or electronic format but primarily in human mind, expressed by speech, gestures, motions or thoughts. Knowledge management can be positioned on one of the higher levels of continuum starting from data, information, knowledge and ending with wisdom. The complexity of the definition increases along this continuum. Data refers to facts, information is data put into a context, but knowledge is much more difficult to define, not to mention definition of wisdom which increases the challenge even more.
I think that organization’s position within this continuum is indirectly related to information management maturity model.
For most of organizations data and information management, with all their challenges, come much easier to be put on the information management roadmap, rather than explicit expanding of capabilities through knowledge.
I like Nonaka’s spiral model with knowledge process with intertwined tacit and explicit knowledge (externalization, combination, internalization and socialization), although it has its own limitations. One of the biggest problems that mature organizations face today is to try to codify the knowledge so it could be shared or used collectively. Great example is project’s lessons learned. All project managers know that this should be produced at least at certain stage of the project lifecycle. And what happens? PMO collects them but very few project managers make any use of them. Lack of standard codification of lessons learned, and related lack of context, make them of little use. The knowledge transfer process breaks.
Better approach is to use access to experts to provide coaching for such transfer. The human interaction allows for better alignment with the needs.
Big push for knowledge management comes nowadays from introduction of social networking. It became already part of our lives, however organizations still struggle with the concept and how to tap into this enormous knowledge repository. This is quite interesting topic and I am working on a paper addressing this. Coming soon….
(This article was originally published on Pragmatic Marketing.com)
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:
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?
Recent Comments