Two new tools are included in the next release of TeamWorks PPM to help organisations improve their project governance.
Project lifecycle processes. All projects have stages they must follow from start up to close down. Within these stages, actions and decisions need to be undertaken by the project manger, stakeholders and other people involved in the project. For example a business case may need approval and a budget allocated before the project can start. Once the project starts up a risk assessment may need to be done and a quality plan drafted.
The next release of TeamWorks PPM allows the system administrator to set up a range of pre-defined processes which can be attached to a project.
As the project progresses, the project manager can mark these actions as complete or not required for this particular project. A new dashboard is provided that lets auditors and PMO staff check at a glance which projects are following the defined process.
Project status reports. Most project managers have to produce weekly / monthly status reports and we know it is a pain of a job. The next release of TeamWorks PPM includes the facility to build status reports directly within the software tool. As TeamWorks has knowledge of a projects RAG status, issues, risks, costs etc it is a simple matter of selecting items from a pick list to include them in the report.
Reports can be worked on over time until finally published to a status report dashboard. Not only does this dashboard provide a single source for all the status reports in the organisation - but it also allows stakeholders and PMO staff to see which projects are missing or are late producing status reports.
Both of these features plus a host of others are due to ship in TeamWorks PPM 3.2.
admin TeamWorks, governance, risk management
Every couple of weeks we get contacted by someone asking if our project management software TeamWorks is free (of charge). When I politely tell them that actually no, it is not free they always seem a bit disgruntled.
So, after I explain that our employees have bills to pay, kids to feed and our salaries are paid because we charge for software…. I then start explaining further why our software is not free - and that software that appears “free” is not.
- “Free” software started as a matter of liberty and not of price and this point is well summarised here. Free means free to fix, augment and share things back with the community. If you are not going to do this, then why not contribute money to the free software foundation.
- Everything has a cost. Freeware has ended up costing something to someone, somewhere down the line.
- Companies like iPlanWare invest a substantial amount of time and money in their products. Good design costs and we have to pay for our R&D somehow.
- Software needs supporting. I don’t mean just bug fixes but general help with the software - “how do I do?” type questions. Who is going to support the freeware you use? This is exactly why organisations like sugarcrm offer a “commercial open source” option. When you investigate the pricing of commercial “paid” freeware you quickly realise it is going to cost you the same as regular paid software.
- With freeware you have the option to fix and augment the software yourself. But are you really going to do this? Or are you just going to use it? If so refer back to point 1.
I have a couple of builders quoting me for a new extension at the moment. Perhaps I will ask them if they would build it for free. No wait a minute, next time someone asks me if our software is free, I will tell them yes, if you give us some of your organisations products or time to the same value for free. Seems fair?
I should stress, I have nothing against freeware and use quite a few freeware products myself. In fact this blog is created using freeware. And in thanks I have answered quite a few questions posted by Wordpress users to problems we have also encountered.
admin Business of software, Commercials, TeamWorks
I don’t really understand why software vendors keep introducing new terminology for the same thing. I guess it is the marketing departments trying to give the sales team something “new” to take to prospects.
In early 2001 when iPlanWare started offering our software as an offsite solution (i.e. customers didn’t have to install any software) this was called hosted software. We hosted it for them, they paid us - simple. For some reason the industry then migrated to calling this ASP or application service provision.
Ok, so we lived with that for a couple more years then someone decided ASP was old hat and we needed yet another term for the same offering. So SaaS or software as a service was born. Same software, same deal - new name.
And now we have cloud computing - whatever next. Let’s just get something clear - hosted software, ASP, SaaS, software as a service or cloud computing we are talking the same concept. Software that you don’t install or manage. If you want to know more about the advantages of SaaS take a look here. And remember you can always take our TeamWorks PPM software onsite also.
Ian Harrison Hosted, SaaS
You will find many definitions of risk management available and I don’t intend adding another. But in a project management context, risk management is a way of managing the uncertainty around your project.
A risk in its simplest form is something that may happen and may have a positive or negative impact. But most people when undertaking risk management focus on negative risks - I guess positive risks are a bonus if they happen.
If we accept that things will go wrong on projects (and they do!), it certainly helps to have a structured approach. So in a nutshell, here are the key steps:
Identify your risks. Figure out the things that could have a negative impact on your project. For example “no resources”. Don’t just copy the same risks from your last project risk log - I know some risks will probably be the same across most projects. But spend the time figuring out what could go wrong on this project.
Assess your risks. Here you are capturing some factors against the risks. Typical factors captured are probability (how likely is it to happen) and impact (how big a problem will it be). Some people use 0-100 or high/medium/low. It can also be useful to capture a financial impact if it happens.
Define a response for your risks. This is the fun bit - figuring our how you intend to deal with the risks. Here are the typical risk responses.
- Avoid the risk. Do something to remove it. In our example above, this may be to reduce the amount of work in the project. Therefore the risk can’t happen as there are plenty of people to do the work.
- Transfer the risk. I like this one - make it someone else’s problem. So in our example above we could transfer some of the work to a supplier.
- Mitigate the risk. Do something to lessen the likelihood of it happening or the impact if it happens. So in our example above we get an overtime agreement in place from our resources.
- Accept the risk. Pretty obvious this one. Do nothing - the risk may have such a small impact it is not worth worrying about.
Most of the above will be captured in a risk log. In you take a look at TeamWorks you will find we have a risk log built into the product which automatically ranks projects by risk level. Far better than using a spreadsheet.
Once you have your risks in place you can then start doing meaningful analysis over your project portfolio. For example which are our most risky projects? What would be the financial impact if the most probable risks happened?
So why do risk management?
- It is not difficult to do and will have a positive impact on your project outcome.
- Identifying the most risky projects means you can zone in on those projects at each review cycle.
- You avoid the “no one told me” culture.
Ian Harrison TeamWorks, risk management
