Book Review: Project Governance

The July 2009 book review from Project Management Tipoffs (brought to you by Arras People) covers Ralf Muller’s book entitled, “Project Governance.”

The concept of the book is that without a governance structure, an organization runs the risk of conflicts and inconsistencies between the various means of achieving organizational goals, the processes and resources, causing costly inefficiencies that impact negatively on both smooth running and bottom line profitability. Please read on…

Project Governance

A night to read and some real practical solutions to implementing governance in your organisation – either at portfolio, programme or project level. “Project Governance” from Ralf Muller is a little misleading as it doesn’t just cover project level governance. Starting at the corporate level, with academic theory, the book soon moves onto programme and project governance taking into account different organisational models. Is your organisation a “Flexible Economist Paradigm”? Or in others words has your organisation established project management as a core competence, with professional project managers? Governance within this environment will follow a different path to that of a “Conformist Paradigm” organisation where project management is performed by technical experts as an on-the-side task.

So what is governance and why would you want to know more about this area of project management? Governance is defined in the book as:

“Governance provides a framework for ethical decision making and managerial action within an organisation that is based on transparency, accountability and defined roles”

This book covers everything from portfolio management, sponsors & steering groups, strategic and tactical project management offices, programme management, in fact it brings together a lot of areas and topics already within the public domain. There are two sections that are particularly worthy of note; a governance framework for project management and how much governance is enough? The framework provides a three step process which enables an organisation to increase its PPM governance. Within each step there are three areas; what can be done, what should be done and what is done. Step 1, includes basic training and methodology use (it talks about the adoption of methodologies such as PRINCE2), introducing steering committees (ensuring what is learnt is adopted and put into use) and the use of audits and reviews to ensure the “what is done” or learnt has translated to successful project delivery.  A simple framework which covers the different levels of organisational maturity has been conveyed well in this book and would be a welcome addition to any programme office manager, portfolio manager or organisational change specialist’s bookshelf.  That said, this is also a book aimed at the project manager, especially their role within project governance but also programme level, portfolio level and ultimately how their delivery impacts the corporation as a whole.

Knowing when there is enough governance – appropriate to your organisation and the programmes and projects it delivers – is also covered. A simple approach which focuses on the relationship between project manager and steering group and the roles & responsibilities of each may be useful insight for any project manager.  Like much in project management, communication is the key for effective governance at each level of the organisation and Muller’s book goes a long way to showing how to utilise effective communication to achieve a integrated governance model.

More information and review text about Mr. Muller’s book, as well ordering information, is available at Gower Publishing.

Balancing Critical Project Success Factors – Engaging Conflicts Directly

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” This is the fifth installment in a six-part series entitled Balancing Critical Project Success Factors. In case you’ve missed the first four, here’s what we’ve covered so far:

• Introduction
• Selling Good Ideas
• Building a Common Vision
• Generating a Commitment to Ideas

In this fifth segment we cover engaging conflicts directly and resolving them efficiently and effectively.

Engage Conflicts Directly and Resolve Conflicts Efficiently and Effectively

Once project plans are underway, change happens. Requirements shift, the client does not meet its obligations in the project plan, and budgets can be reduced. Changes within the IT group can also occur. Tasks may exceed initial estimates. Key programmers leave to join other firms. Differences in opinion among IT professionals about the best approach can erupt into conflicts that push projects off track.

When this happens, IT professionals must assertively engage key stakeholders (e.g., users, user management, IT management) in problem solving about the trade-offs that must be made in quality, time, cost, and perhaps even customer service agreements. Assertiveness is critical because users (and admittedly IT management on occasion) would prefer to avoid making necessary but difficult decisions about trade-offs between quality, time, and cost. Interestingly, resolving such conflicts may be best viewed as a typical and not unusual part of what IT project managers do. In survey research of professional project managers, it was discovered that they report spending an average of 12 hours per week resolving conflicts.

When engaged in problem solving about trade-offs, stakeholders sometimes become frustrated and retaliate by challenging the competence or creativity of the IT project manager. IT professionals sometimes respond to such challenges by retreating from their legitimate interests. In a misguided effort to please, some over-commit to all three factors although significant changes in the project environment necessitate adjustments. The result is priority overload, stressed-out IT personnel, a loss of credibility and influence, suboptimal IT work products, or missed timelines.

Assertively championing one’s basic interests, exploring alternatives with affected parties even when they are not enthusiastic to do so, and collaborating to construct win-win agreements is the better response. Unfortunately, many people drawn to information technology (like many drawn to other technical disciplines) have a personal aversion to conflict. Consequently, for some IT professionals, enhanced negotiation skills is necessary.

Faithfully applying project management disciplines can limit the amount and scope of project conflicts that IT professionals have to manage. Conducting risk assessments early in the project life cycle to identify factors that might threaten project deliverables is one such discipline. If a risk is detected early (e.g., weak user management consensus on requirements) and focused problem solving occurs about what contingencies are necessary to address it (e.g., identifying a resource that can be used to do team conflict resolution with user managers), project disruptions caused by the risk can be effectively contained.

Providing regular user management updates is a second project management discipline. When updates work most effectively, not only is progress reported, but threats to project deliverables are reviewed and user management support of efforts to limit or resolve those threats is secured.

For some complex projects, more substantial organizational conflict management mechanisms are required. On large IT initiatives, the relative priority of the needs of different user groups can change over time. Because IT resources are often relatively fixed, reallocating resources to respond to a increased urgency for one user often means reneging on commitments made to other users. To address shifting priorities between users, some IT groups convene regular, periodic meetings of steering committees or users councils. When such mechanisms work well, users collectively learn about urgent priority changes, explore alternative responses to these situations, and finally make mutual decisions about priority changes and IT resource reallocation. In these settings, IT professionals facilitate the preparation of information that enables these groups to make sound decisions. By promoting quality dialogue between users, IT professionals enhance organizational problem solving.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Balancing Critical Project Success Factors – Selling Good Ideas

This article contains another excerpt from Paul Tinnirello’s book “New Directions in Project Management.” In the Introduction article we outlined the five prescriptions for preserving the balance between project success factors. In this article, we look at the first prescription – sell good ideas by emphasizing benefits that the user perceives as valuable.

Selling Good Ideas

The starting point for an IT project is selling senior management within the user group and within the IT function on the idea. Consequently, the efficiency with which ideas are sold is one important means of managing priority pressure. The power of persuasion depends largely on whether the rationale used to support an idea resonates with the decision-maker’s interests. To sell ideas more efficiently, the rationale for an idea must reflect the user’s priorities. In short, reasoning should always outline “what is in it for them.”

When selling ideas, IT professionals sometimes get stuck on technical issues, specifications, and justifications. Although technical details are critical, as facts, they have limited power to influence users and senior IT management. As a result, one of the main priority management prescriptions is that IT professionals need to develop sufficient business expertise to engage users in terms that they will find compelling. IT professionals who add this expertise to their technical competence have the greatest organizational impact. Many IT organizations are experimenting with the role of user or client relationship manager to help establish client sensitivity within IT organization.

Selling ideas effectively also means having good ideas. Good ideas are designed with knowledge of the practical time and resource constraints within which they will be implemented. Not all business problems require state-of-the-art solutions.  Sometimes, small is beautiful. Making incremental enhancements over time can moderate the negative influence of organizational politics, limit risk, and create success experiences. A track record of successful enhancements can build momentum for bigger, more ambitious projects.

Having a good idea is not sufficient, however. Good ideas are often not met with enthusiasm. How the IT professional responds to the objections raised by others as the idea is being sold affects one’s eventual success. Arthur Schopenhauer, the nineteenth-century philosopher said that ideas go “through three distinct phases: ridicule, opposition, and finally enthusiastic acceptance.” Advancing ideas through these phases means (1) increasing perceived need for the idea, (2) modifying the idea itself to increase personal and organizational benefits to key stakeholders, (3) reducing costs, both personal and organizational, and (4) decreasing perceived risks. By adjusting good ideas iteratively based on feedback from stakeholders, IT professionals can efficiently win a critical mass of support for IT projects from key stakeholders.

Paul C. Tinnirello is the editor of “New Directions in Project Management” from the Best Practices Series.

Job : Siebel CRM Senior Project Manager

Another job posting that I came across…

Our global multinational client in Lausanne, Switzerland is now looking for a Senior Siebel Project Manager / Program Manager to join a long term basis (ideally permanent).

There is the possibility to join as contract initially but this will only be given to candidates based in Switzerland or looking to relocate on a long term basis in the French speaking part of Switzerland.

THE ROLE:
Senior PM for Siebel implementation with role evolving to Program Manager (multiple projects / more countries) as Siebel initiative is planned across next 3 years. You will be in charge of the overall Siebel global implementation.

YOU NEED:
At least 10 years CRM projects,Siebel experience (SFA/BI/Call Centre), global/large scale projects(multi-country deployment), strong project management skills(end-to-end project life cycle, good command of all project areas;technical, process, change, etc.), process manufacturing experience,strong communications skills, experience of vendor management.

- University degree or equivalent. Good education is mandatory.
- Fluency in English (written and spoken) mandatory + French speaking will be an advantage.
- At least 10 years large complex international experience in delivery of IT/consulting services in the area of CRM with indepth expertise in implementing CRM software such as Oracle CRM/Siebel
- Experience on business process re-engineering;
- Experience in international working environments; Experience of off-shore delivery model
- Management of project teams
- Advanced business consulting competencies

Nice to have
- Deep understanding of leading and emerging IT solutions; experience of Siebel on-demand will be appreciated
- Selling skills on high added value services
- Good business acumen for marketing and sales in specific industry / process manufacturing / chemical are an advantage

If this sounds like your next challenge and you would like to live/work/play in Switzerland please send us your cv ASAP. We will call you shortly to discuss it in details.

- Apply here.

Eight Things Your Business Analysts Need to Know

This information was culled from an ESI International white paper obtained during gantthead’s 2009 virtual PMXPO today.  I found this document very interesting and it provided nice insight from the BA perspective as opposed to the PM perspective.  The document is too long to include here in full, but I’ll provide some highlights.

Why Are Projects Failing?

In an online poll of 2,000 business professionals, the question was asked, “What are the key challenges in translating user needs into system specifications for mission critical projects?”  50% stated poor requirements definition as the key challenge.  Inadequate risk management (17%), poor scope control (15%), and communication problems (14%) followed far behind as key challenges. 

If a project fails, it’s often assumed to be the project manager’s fault. More and more, however, research is showing that this is not the case. In this survey, with an overwhelming 50% of respondents citing poor requirements de?nition as their biggest challenge, it seems to raise a new question. When projects fail, most organizations are quick to blame the project manager. But what about the business analysts? What role do they play? More importantly, what role should they play?

Role of the Business Analyst

At the most basic level, a business analyst acts as a translator or liaison between the customer or user and the IT person or group attempting to meet this user’s needs. According to the International Institute of Business Analysis, business analysts are “responsible for identifying the business needs of their clients and stakeholders, to determine solutions to business problems.”

The follow-up question, therefore, is “what competencies does a business analyst need to accomplish these tasks successfully?”  ESI’s white paper presents the following eight competencies as key for the business analyst.

Competency #1: Eliciting Requirements

On the most basic level, we know that a big part of a business analyst’s job is to gather and document user requirements. Requirements can be conditions, functionality, products or services for internal or external use.  They are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results—that’s someone else’s job.

Competency #2: Creating the Business Requirements Document

A business requirements document (BRD) is an exhaustive written study of all facets of regulatory, business, user, functional or non-functional requirements and provides insight into both the as-is and to-be states of the business area.  It is a detailed pro?le of primary and secondary user communities. It comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst.  After the document is completed, the business analyst and the client or user meet for a formal review and for approval of the BRD. The document is then shared with the rest of the development team, including the project manager.

Competency #3: Structured Analysis

Structured analysis refers to the art of modeling.  In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, ?nally, organize information into coherent ideas. The most common types of business analysis models include business models, process models, data models and work?ow models.

Competency #4: Object-Oriented Analysis

Within a business context, an object model is an abstract representation of the process and data requirements of a system, based on decomposing the system into units called objects. Each object encompasses the data and operational characteristics of one business item. Object-oriented analysis is particularly important to business analysts as a business planning tool to depict the hierarchy of business functions, processes and sub-processes within an organization.

Competency #5: Testing

When it comes to testing in business analysis, the ?rst thing to understand is that the term applies to several di?erent levels of work. First, business analysts are looking to test the products to validate whether the requirements have been met.  They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be models. Testing requirements should be done in iterative stages to ensure that, by following the requirements, the desired deliverables will be met.

Competency #6: End-User Support

It’s a common misconception among project teams that the project ends when the deliverable is completed. Not so. Business analysts, speci?cally, should be aware that end-user support after the product is delivered is almost as important. It should be stated, too, that the role of the business analyst is not to act on behalf of the training team, but to complement the training team’s e?orts with their knowledge of the business requirements.

Competency #7: IT Fluency

How much knowledge is enough for a business analyst? With regards to IT knowledge, this has been a long-standing debate. In reality, the answer is as varied as it would be for any other professional. The amount of necessary IT knowledge is truly based on the project. The IT background for a competent business analyst depends entirely on the environment and possibly the industry vertical he or she works within.

Competency #8: Business Process Re-Engineering

Business process re-engineering (BPR) is a competency in which all levels of business analysts must be highly skilled. The junior business analyst’s responsibility is often to identify, using various modeling techniques, possible areas of improvement. The intermediate business analyst might have the job of walking the client or user through each step of the process, examining individual tasks that could potentially be improved. The senior business analyst begins to actually make suggestions for improvements.

My Summary

I can’t say that I agree 100% with this white paper, but I feel that it touches pretty well on the key responsibilities of the Business Analyst on an IT project.  How those responsibilities line up with the phases of the project and who approves what differs from my over all project management methodology and approach, but the concepts are basically the same.