A couple of weeks ago I wend hiking in Belgium with my Scouts. And it was really nice, good weather, a nice route. After one and a half day we crossed a road which leads to the village Hotton, and we knew we also had to go through that village. One of the Scouts suggested: “Why not follow that road…. that’s faster than hiking up and down that hill in front of us”. Of course we didn’t follow the road, not only because it was a drive-too-fast-don’t-pay-attention-to-pedestrions-because-they-shouldn’t-be-there-anyway-road, but mainly because Hotton was not the goal of the day. The route was the goal. Hike through a nice environment, enjoy the view, enjoy the route.
This is different in projects. Projects are about the end goal, the business case, the benefits. And of course if you have no fun at working towards that goal, find other work. But the only reason for doing the project is reaching the goal. So if you find a fast route towards the end goal, you take it. No detours just for fun, no “sitting around, enjoying the view”….
That’s not always easy. Not only the senior user/business/client has a tendency to add as much as possible to the scope of the project, without verifying if it serves “the big plan”. Also developers like to add as much to the scope as possible, to deliver the best and complete product possible. However there is also time, money, quality, etc to consider.
So I guess in a project with every step you take, consider: “Does this have a positive influence on the goal?”.
Filed under: Project Management, Scouting, Thoughts, Work |
on LinkedIn
Toms blog 
Hi Tom,
In my past I have had many times where I was one of those developers or analysts or even the project manager who thought pleasing the business during the project would also make them happy at the end.
I was wrong and I have learned from it. Nowadays I try to make sure that the client sees that I do watch for their endgoals, benefits. Even sometimes I have been told NOT to talk about ROI too much, but I just kept pursuing it, because without a proper ROI the client will not be happy at the end.
Eventually a good long relation ship means that the product of the client continues for years and years, not just the first year. If during those years and years you are able to talk and think with the client about their goals, then usually they’ll stick with you.
Ha
Hi Tom,
I agree fully that the end-goal is the most important part of a project, of-course the end-goal should be defined together with the customer and the vendor so that everybody has the same goal in sight.
On the other hand i have learned during my time at CMG that there are many sub-goals which are sometimes just as important. because for as well as the customer and the vendor it is about continuation of their business. Companies should grow because standing still is going back. Customers define these goals to grow in their business case and as a vendor we will help them to make this business case..99% this is about money, profit, saving costs etc.
For a Vendor this is also the case, we want to make money..but a project is also a great way to learn, for everybody who is on a project. learning new techniques, new products, communication, growing in your function or even promotion.
For a vendor these goals should be taken in consideration when starting a project.. A customer is probably also doing this, he can also have project assistents in a project who wants to grow to a project manager and they are investing in this.. this makes projects also fun for people and they see continuation in their career. At CMG this was mandatory for sales and project managers.. to sell juniors, coach them..even in the extreme way the customer paid for trainings!
So if it is possible (also very important ofcourse) , then sometimes you should take the detour to get new information and learn from what you are seeing..enjoying the view is sometimes a great way to open your mind and learn!!
Roan
Basically you’re right, but you should be really careful when defining those goals for the project.
You may have a goal to “deliver the site with features XYZ by DD-MM-YYYY no matter what” and achieve that, but then find out there were other important things to consider. For example you may find out your developers were always “taking the shortest way” and produced absolutely un-maintainable code which makes any change too expensive to implement.
And then you realize that, in fact, making nice code, optimization and other “optional things” (=”enjoying the view”) also have sense for the final goal.
So I agree with Roan – that sub-goals are also important.
And if you’re able to formulate all of your important goals and sub-goals you’re much closer to success 🙂
@ Roan: of course training juniors is really important. But directly charge it to clients? I thought that is just part of the normal hour rates and counted as internal costs….
@ Christine: I see what you mean, but isn’t that maintaining a basic quality while going towards the end goal?
It is not only about Juniors, but about everybody in the organization and who participate in a project. And about charging direct to the customer.. this is an example which happens indeed. An example was that a customer needed a consultant with specific knowledge. that knowledge was not important for the vendor because he cannot ‘re-use’ that knowledge somewhere else, so the customer paid directly for that training….but as i said..it is just and example…for example adding a junior project manager next to a senior project manager in a project where the junior ‘helps’ the senior PM and participate in meetings etc. to learn. mostly in the end of the project when there are no risks anymore, the junior takes over the PM role from the senior…