Project Management

My Professional Journey

by
Sharing Insights from my Professional life , where I have been a Sales Engineer, A Health Professional and now , a Project Management Professional. These blogs encompass my observations or experiences. They may be regarding the Projects that I have led or been a part of or something close to our daily lives like Mindfulness and health which may affect our productivity as Project Managers.

About this Blog

RSS

Recent Posts

Define "Digital Project Manager" for me

The Pain of Legacy Systems

How a PMPĀ® helped me improve my PMSpeak

Selling Ice to an Eskimo

The Local Coffee Shop - My Conversation Catalyst

Categories

Accountability, Business Analysis, Certification, Content Management Systems, Conversational Intelligence, Documentation, Emotional Intelligence, Enterprise Analysis, Influencing, Information Security, Intranet, Leadership, Lessons Learned, Mentoring, Performance Testing, Personal growth, Prince2, Product Marketing, Progress Theme, Project Documentation, Project Management, Promotion, Quality, Sales Engineer, Surveys

Date

From Business Analysis to Enterprise Analysis

linkedin twitter facebook Request to reuse this  

We once had a Senior Manager who introduced the concept of "domains" within the Business Analysis Practice.

My good friend was a Business Analyst then and I asked him what that meant in the context of his day-to-day job. He replied " A Business Analyst  is assigned to a  business units or conceptually , " A Domain " and we analyse IT projects which get allocated to that "Domain". I couldn't quite get the grasp of what he said then as this was about five years ago.

After reading about the Business Analysis Body of Knowledge (BABOK) to gain more perspective into how a Business Analysis contributes to projects other than merely capturing requirements, The "domain" concept has become much clear It's more broadly , the concept of Enterprise Analysis.

The focus of these "domain" experts or Enterprise Analysts is not to work on initiatives in silos but, to map out the Business Process of the entire Business Unit eg Manufacturing. Manufacturing typically encapsulates Logistics, Supply Chain, Testing, Creating a Product and several others . When an Enterprise Analyst gets to work they understand the business process of each of these different streams of work in this Business Unit. They understand and map how these Units achieve synergy and congruence and how they work cohesively achieve a common goal - To get a Quality Product out of the door.

There could be an initiative to improve efficiency in one of these streams and the Enterprise Analyst here plays a paramount role in analyzing how this will affect the other stream of work. Although they may not influence the final outcome or the choice of solution, they would have played a valuable role in determining a key requirement or a future in-scope item for the other stream . Their analysis could even fuel the need or justify the organization's investment in a future project in the same Business Unit for another stream of work. An Enterprise Analyst can also develop a bank of reusable requirements which they can readily leverage on a different project within the same domain.

And If a new Project Manager is hired to deliver a project which belongs to the domain of work in which we have our experienced Enterprise Analyst, How much of a front foot the Project Manager already finds themselves in? The Business Process is largely mapped out, The scope is a lot clearer and the amount of work that a Project Manager needs to put forth a detailed business proposal or build a business case is already reduced.  In addition, the Enterprise Analyst is already aware of some of the Business or Project Risks in their domain of expertise. Then the Enterprise Analyst partners effectively with the Project Manager to deliver a well -scoped and well - planned Project.

Enterprise Analysts are the "big" picture people who can provide insight into how a new Project may fit into the Organizational context and can also assist in prioritizing projects and the Business Planning cycles of Organizations.

They are valuable assets to any Organization and a very good career choice or advancement option for bright Business Analysts.

What has been your experience in this regards?

(image courtesy :- dataversity.net)

Posted on: January 11, 2017 10:42 PM | Permalink | Comments (0)

The Documentation Conundrum

linkedin twitter facebook Request to reuse this  

A new Project starts . As a Project Manager, you are full of enthusiasm , embarking on the exciting new challenge .

Your project will deliver an exciting new product, an upgrade or a process improvement. Whatever be the case, the documentation - Solution Architecture, Support Plan, System Test Plan, User Acceptance Testing Report , these are all the proof that it will be delivered according to what the customer wants.

After a workshop(Or many) the documentation and artifacts that your project will deliver is agreed. That's the easy part.

And yes we have also established why some of these are more important than others because:-

  1. We need them for auditing and regulatory requirements.
  2. This is a waterfall project and not producing them is unheard of.
  3. We have vendors and third parties delivering the project for us.Therefore we do need them to produce documentation so we can support the solution moving forward.

Perhaps agreeing on who will approve and review the documents is also the easy part. maybe even agreeing on the method of approval - wet signatures, electronic signatures or email approval are easy. The production of the documentation is also not the difficult part.

Then what exactly is the difficult part and the reason for writing this article? It's the review of the documentation.

Often stakeholders may assume ownership as reviewers and approvers of documents but when it actually comes to requesting them to review or approve, you could be facing one of the many challenges

  1. They are busy on another project.
  2. Their managers have given them the task of a higher priority than reviewing your document.
  3. After several review cycles and to-ing and Fro-ing, they seem to pick something new in the document which they have not hitherto talked about.
  4. Their delegates also confirm to points 1 , 2 , 3.
  5. Your document is to be reviewed by different groups of stakeholders with different interests in the outcome of this project and it's often a nightmare to get consensus on the contents of the document based on feedback from the many groups.
  6. The reviews may be too granular than what the document intends to convey or their comments may not be entirely relevant to the document they are reviewing.
  7. You have had walk-through of the document with them, however they are still not happy.

No matter how electronic or automated your process becomes, there is always a human being behind that computer who needs to approve the work that your project is delivering.

Yes there may be effective strategies to review and approve Project documentation . what are some of these innovative strategies? I request some inputs.

Posted on: January 11, 2017 10:37 PM | Permalink | Comments (0)

Intranet :- Usefulness and Currency

linkedin twitter facebook Request to reuse this  

What is an Intranet? simply put , it's a private network , accessible to an organization's staff , serving as an important focal point of internal communication and collaboration. It also provides "useful" and "current" information to the staff.

Having participated in a project for the procurement of the Content Management System that enables the creation of the corporate Intranet , I have seen the sheer amount of effort undertaken by the project team, not limited to :-

1.   Hiring an external agency specializing in Content Management Systems (CMS) to help create the Requirements Document to ensure that Industry best practices are followed and the chaff is separated from the wheat when it comes to procuring the best and fit-for-purpose tool for intranet content creation and management.

2.   Going through a tender process and selecting the most suitable provider of a Content Management System (CMS) that adheres to the organization's technology road map among other considerations like support and cost.

3.   Creating a project team to work closely with the external agency during the project.

4.   Configuring the Content Management system with all the bells and whistles like Portals, Instant Messaging, Blogging.

5.   Providing training and handover to the system administrators and content creators of each of the Business units.

As with any project, Benefits realization is an important, post-project activity that must be undertaken by the incumbent department that accepts the Project's deliverable.

When the project is finished and the CMS is in operational use, my humble guess is that if we look at Corporate Intranets across different organizations, some common themes may emerge:-

1.   The Home page contains the most upto-date content , links to the most important resources that the staff uses on a daily basis . This is primarily because, there is a dedicated "Intranet" team looking after the home-page content.

2.   As you click on the links and traverse to the pages underneath , you start finding out-dated information. For example you see "please contact..." in a departmental information page and that staff member no longer works for the organization.

3.   The homepage follows the "corporate branding" and the color scheme and a number of sub pages stray away from that.

4.   You see that some projects that finished two years ago under the "Current Projects" list and information in several others haven't been updated for months.

5.   Notorious are the organizational structures that are outdated and no longer exist in the company.

Notable here is that the Business/User Requirements document may or may not have statements like " The CMS must enable the organization to keep it's content 'current' and 'useful' " . May be the "Expected Benefits" section of the Project Management Plan may allude to this, however, in the end, the CMS is only the "enabler", with the onus being on the users to keep the corporate content current and useful.

Also , "Not maintaining the currency and usefulness of the Corporate Intranet" is never recorded as an expected "Dis-Benefit" in the Project Management Plan , because every company has good intentions when it procures the CMS in the first place and therefore such a dis-benefit is never specifically expected. It may however feature in the Risk Register with specific mitigation actions; however, once the project is complete, the following responsibilities lie with the ongoing maintenance of the new software

The owner of that risk "Not maintaining the currency and usefulness of the Corporate Intranet" is the Team that "owns" the corporate intranet platform (let's call it the Intranet Management Team). The Intranet Management Team may not be solely responsible for "currency" and "usefulness" of all the information published on the intranet. They may not even have sufficient number of staff looking after the Intranet. The Intranet Management Team still has the responsibility of ensuring that the content is kept "current" and "useful" but it needs significant communication and collaboration with the other departments that publish information.

Content creators need to know that their job does not end simply by designing their content based on the organization's policies and procedures of "code of conduct", "information privacy" or "content appropriateness”. They also need to be pro-active in managing the currency and usefulness of the content.

Every year the management diligently conducts surveys to hear from staff regarding what is working well and what is not. Often the big ticket items in these surveys happen to be "Communication" and "Change Management".

A glaring question is this :-

If the organization is unable to do a good job of keeping it's corporate intranet current and useful, how does it expect the staff to answer the yearly survey question of " Is my company doing a good job of communicating changes?"

Seeing that the homepage of the Intranet has proven as the best way to capture the immediate attention of the staff , can't the corporate leadership team drive home the point that the content managers across the organization need to take a good look at their content and update it?

Some suggestions are:-

1.   Use the Intranet home page to inform departments that they need to update their content

2.   Spawn a new project for Content Management which looks at removal of defunct links and expired content and re-assessment of adherence of content to corporate branding

3.   Empower the existing Intranet team with more staff members, specifically with the job to contact content managers to make sure that they keep the information current

4.   Assign a central content manager within teams with the added responsibility of keeping the departmental content current

5.   Mobilize an Information Architecture and Governance team to re-enforce the content currency and usefulness best practices

At a time where our smart phones are flooded with social media apps and we spend a majority of our day keeping in touch with what's going on around the world and do expect that news to be current and useful, would it not make sense for us as corporate citizens to contribute to the "currency" and "usefulness" of the information within our own Corporate Intranet?

In closing , no amount of sophistication in technology is going to succeed in providing a solution to corporate problems if the humans using the technology do not take a proactive step.

Would love to hear thoughts from other members regarding their experience with / or leading projects implementing Intranet or Content Management Systems

(image courtesy :- thoughtfarmer.com)

Posted on: January 11, 2017 10:33 PM | Permalink | Comments (1)
ADVERTISEMENTS

"Among those whom I like or admire, I can find no common denominator; but among those whom I love, I can: All of them can make me laugh."

- W.H. Auden

ADVERTISEMENT

Sponsors