Assessing a training programme
Posted by Elizabeth
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 »
5 steps to a project manager competency framework (part 2)
Posted by Elizabeth
Recently I attended a webinar hosted by J. LeRoy Ward from ESI on the role of competency frameworks in developing project managers and how you can build your own competency model for your company. He presented a five-step approach:
- Define the categories of projects that the organisation is working on.
- Identify competencies for project managers.
- Assess your project managers against these competencies.
- Identify what you need to do to get people to where they need to be.
- Execute well, monitor how it is going and measure the results.
Last week I looked at the first two of these points, and today I will cover the final three. So let’s start with:
Read more »
Are You Using the Tools, or Are the Tools Using You?
Posted by Brad Egeland
We have all kinds of tools to get information concerning our project distributed to the right people, don’t we? We have MS Project or similar projects like Seavus’ Project Planner to use for managing our project schedule. Word helps up put together project status meeting notes, project document and plan deliverables, and status reports. Sometimes Excel can do the same – plus it’s great for project budgeting and forecasting. For resource management it’s back to MS Project or another project scheduling tool or you can do it the old fashioned way with a spreadsheet like Excel. And Visio helps us put together meaningful flowcharts for functional and technical design documents and other related project materials. Finally, email is often our primary communication tool on projects. Since communication is probably the most critical function of the project manager, email is in heavy use throughout every engagement.
Throughout the project, the project manager and the rest of the project team are utilizing these tools to create visual, professional, and hopefully meaningful and useful project documents to give to the customer and show to the organization’s executive management. In fact, if the project manager is overseeing five or six or even more projects at once, the creation of these documents and files with these tools can end up taking most of his available time. Especially if accuracy and perfection is a goal – and it should be.
Don’t forget the personal side
What we need to always be aware of, however, is that our customer needs more than just information about the project. And for communication they need more than daily emails. It isn’t always about what we can produce for them and how professional it looks. The project manager must be able to connect with the customer on a more personal level than with schedules, charts, and reports. In order to maintain the highest level of customer satisfaction, the customer must feel like they are ‘in touch’ with the project and the project team. That isn’t likely to happen if all they see are emails coming their way with information and professional-looking document attachments.
Running a Project is Sort of Like Raising a Baby – Sort of
Posted by Brad Egeland
I have a large family – and thankfully that family became a little larger three weeks ago today so this article topic seems appropriate. It came to me earlier this week that running a project from start to finish is kind of like raising a baby from infant to adulthood. Ok, it’s a stretch, but there are similarities.
It could be that this all came about in my mind as a result of several straight relatively sleepless nights. Or maybe I am on to something. Who knows? But the more I thought about it the more I realized that there are some relative similarities.
Pregnancy = pre-engagement/sales
Think of all the work that goes into the pre-engagement portion of the project … basically the sales portion. This is what happens before handoff of the project to the project manager. So, Sales = 9 months of pregnancy. Are you staying with me so far? When handoff is ready to happen, you kind of know what you’re getting – or at least you think you do. In reality, it may be close but there are lots of details that you really have no clue about and you have to dig deeper so you know what you’ve just gotten yourself into.
Delivery = kickoff
The actual delivery is somewhat like project kickoff. It’s when you finally see some early details of the project up close … live and in person. Just like you get some new and very key information from the customer you also get some initial information from the doctors and learn if there are any conditions of your baby that need immediate attention.
Infanthood/toddler = design
The infant and toddler stages = design, in my opinion. Just as you’re designing the system to the requirements of the customer, you’re also training your infant/toddler what’s right and what’s wrong and hopefully molding them to meet yours and God’s requirements for a well-rounded individual. And, just like designing to the customer’s requirements, it’s not very easy and it does often involve some re-work and change orders!
June PM Survey: Managing the Project – Part 2
Posted by Brad Egeland
Part 2 of the June PM survey is now available. This 2nd part of the monthly survey again deals with concepts associated with the ongoing management of the project.
The survey is now active and ready for your participation at:
http://www.bradegeland.com/june-survey-part-2.html
In this 2nd part of the survey, we’ll be looking at the following topics:
Definition of project success
For this question, I’m looking for how either you or your organization primarily defines project success. Is it on time project delivery, on budget project delivery, or customer satisfaction? And for those of you who feel it’s something other than those three options, there is a write-in ‘other’ response area available.
Percentage of successful projects delivered
This one will definitely a best-guess scenario because I doubt that anyone has compiled hard numbers on this plus it’s somewhat subjective as to what one would call a ‘successful’ project. I’m trying to get an idea of where our readership stands in regards to successful vs. failed projects. Recent studies – as I’ve reported here in recent articles – place the percentage of failed projects between 62% and 75%. It will be interesting to see where PM Tips readers fall in that spectrum.
Percentage of project revenue from change orders
Change orders are always a love – hate thing. For the PM and team, they are a great way to increase project revenue and executive management loves them. However, it’s often difficult and even uncomfortable for the project manager to present the customer with change orders – unless they are the result of direct customer requests. Also, change orders are a necessary tool to bridge the gap between the originally defined requirements and what reality fleshes out over the course of the engagement.
