Assessing a training programme

If you have been following my series on project management competency models this month, you’ll know that planning the programme to address any gaps in performance is a large piece of work.  As with any project, you need to make sure it is closed down effectively and that the benefits are realised.  So add some tasks to your schedule in Seavus Project Planner or whatever you use to build in an evaluation at the end.  This will give you the opportunity to assess whether or not your training programme – and the associated mentoring, coaching, stretch assignments and so on – have been worth the effort.

Why do we want to assess this?  Well, there isn’t much point investing in training and development unless you are going to receive some benefit from the investment.  Assessment gives you the chance to see whether people are applying what they have learned.  You’ll be able to see if they are using their new skills in their projects and whether their managers are noticing improvements.  Of course, the objectives of every development programme are going to be different.  Perhaps you are using training to motivate or incentivise staff, in which case maybe it doesn’t matter much to you whether they apply what they have learned in the workplace.  However, let’s assume that you do want to assess whether training has been effective.  To do this, you can use Kirkpatrick’s training effectiveness model.
Read more »

Project management competencies: creating a framework

Last week I attended a webinar on development project management competency frameworks, hosted by ESI.  J. LeRoy Ward is an experienced and interesting speaker so I thought I would share some of the highlights from the webinar.

What is ‘competency’

“There is not one universally accepted definition of competency,” said Ward.  ESI use Raymond A. Noe’s definition of competency, which is:  ‘areas of personal capability that enable employees to successfully perform their jobs by achieving outcomes or accomplishing tasks.’  In essence, being competent is not just about having the knowledge but also about being able to apply this in real life to get things done effectively.

A competency framework is a model that sets out what competencies are required in your organisation to be an effective project manager.

Read more »

Better Software Conference & Expo 2009

Software Quality Engineering’s Better Software Conference & Expo is starting next week here in Las Vegas, NV. The conference runs June 8 – 12 at The Venetian Resort, Hotel & Casino. Just as with Interop – which I ended up not making it to due to other commitments – I’m hoping to at least take in the Expo. I have passes secured and all I need to do is find the time.

Below are some details on the conference. If you are reading this and plan to attend, let me know…

The Conference

At the Better Software Conference & EXPO 2009, you’ll become a better, more informed software professional with an outward, customer-focused view of development. Learn about the latest tools, trends, and issues regarding agile development, project management, people & teams, software testing & QA, software requirements, process improvement, metrics, and design & architecture.

Who should attend:

• Software managers, directors, CTOs, and CIOs
• Project managers and leads
• Measurement and process improvement specialists
• Requirements and business analysts
• Software architects
• Lead developers and software engineers
• Security engineers
• Test and QA managers

Topics covered:

• Agile Development
• Project Management
• People & Teams
• Testing & QA
• Requirements
• Process & Metrics
• Design & Architecture

Why Attend:

• Discover the latest in software development technologies, trends, and practices
• Learn the best agile development approaches in the industry today
• Find new ways to wisely manage your software projects and teams
• Discover new measurement approaches to optimize your software investment
• Understand what your customer wants and how to write the requirements to meet these needs

The Expo

Looking for answers? Take time to explore this one-of-a-kind EXPO, designed to bring you the latest solutions in technologies, software, and tools covering all aspects of software development. Throughout the EXPO, participate in technical presentations and demonstrations to help you find the tools and services you need to support and improve your software projects. Meet one-on-one with representatives from some of today’s most progressive and innovative organizations.

Exhibitors that will be displaying at the Expo include: Software Quality Engineering, VMC, Sticky Minds, Rally Software Development, Net Objectives, InnerWorkings, Quantitative Software Management, and many more. The Expo runs till 3pm on Wednesday and Thursday only with reception following.

For more details on the conference and for registration information, visit www.sqe.com/BetterSoftwareConf/.

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.

The difference between projects and programmes

Many of us would class ourselves as project managers, and some of us aspire to be programme managers.  But is programme management just about managing bigger projects?  PMTips spoke to J. LeRoy Ward, author of Dictionary of Project Management Terms and Executive Vice President at ESI International, a global learning company.

What’s the difference between a project and a program?

In my book, Dictionary of Project Management Terms, I define a project as a temporary undertaking to create a unique product or service.  A project has a defined start and end point and specific objectives that, when attained, signify completion.  A programme, on the other hand, is defined as a group of related projects managed in a coordinated way to obtain benefits not available from managing the projects individually.  A programme may also include elements of on-going, operational work.  So, a programme is comprised of multiple projects and is created to obtain broad organizational or technical objectives.  There are many differences between a project and a programme including scope, benefits realization, time, and other variables.  One notable difference is time; for example, a project by definition has a beginning and an end (or at least one hopes so!); certain programmes, while having a beginning may not have an end.  A classic example of one of these types of programmes is an annual construction programme.

There seems to be more information around now on programme management.  Is it really taking off?

I have found in my travels and experience that programme management, although firmly embedded in certain industry verticals such as defence, is a new idea and concept in the commercial area.  During the past several years, I have had many conversations with our clients who are realizing that many of the work initiatives they have undertaken, either for themselves or for their clients, are really programmes, not projects, and they are looking for the best way to manage them.  The U.K. government (Office of Government Commerce) recognized this a while ago when it published Managing Successful Programmes. One can consider it a guide for programme management.  Since it was published in 2003, I have seen an increasing number of books and articles on the topic, but it pales in comparison to the wealth of literature available for project management.  The Project Management Institute has also recognized the value of programme management and recently introduced the Program Management Professional (PgMP®) credential. It appears that programme management, although a concept that has been around for many, many years, is now seeing a greater level of interest in the global community.

How would you define the difference in skill sets between a project and a programme manager?

The skill sets definitely overlap and it’s a bit artificial to try to separate the two.  Nonetheless, there are differences which I tend to see along a continuum.  In my experience as both a project and programme manager, the latter requires more refined skills in business areas such as negotiation, organizational change management, financial management, consensus building, and political savvy.  Additionally, a programme manager needs to always keep his or her eye on the achieving the intended benefits of the program which can be different and apart from the objectives of any individual project.

What differs for a programme manager is the degree of expertise, application, and focus.  Because a programme manager is really more of a business manager, programme managers do not necessarily have strong project management backgrounds.  They hail from a variety of disciplines.  To be sure, one finds many MBA’s as programme managers as well as those having backgrounds in various technical and scientific fields.

Can a project manager ever be a good programme manager?

Yes, of course, but one may never assume that simply because an individual is a competent project manager that he or she will be successful in programme management as well.

One problem that programme managers come up against is the terminology.  If you are working on a programme but your stakeholders still insist  on using the word ‘project’, what can you do to ensure the  message gets across that it is bigger than just one piece of work?

One needs to “drip feed” the notion that what they are working on is really a programme of interconnected projects rather than a project itself.  One way to do this is to make sure that, as a programme manager, one is meeting with all project managers on a regular basis as a group.   As each project manager is providing status and discussing his or her contribution to the greater whole, it will become evident that the work to be done is much broader and more comprehensive than a single project.  That said, there are many companies that have their own vernacular which may be very difficult to change so one should not buck the “system” too much as it simply isn’t worth the political capital.  Focusing on the work to be done, more than the way it is described, will mean success for the programme manager.

That’s great advice, thanks!  Do you have another top tip for effective programme management?

Always keep in mind the stated benefits for launching the programme in the first place.  For example, we are now implementing a content management system in the company.  The reason we are doing this, broadly speaking, is to enable ESI to develop courses faster, better, and with less cost.  The CMS program consists of multiple projects, from organizing our vast library of materials, to technical implementation, training, and other things.  As a programme manager, our VP for Product Development, while needing to ensure that each project is completed, needs to ensure that the sum total of all the projects will meet our overall business goal of facilitating our product development process.  In many programmes, there is a position called “benefits realization manager” simply to ensure that the business benefits are always front and center.

Thanks!