The Odd One Out

The do's and don'ts of projectplans - an overview

Paul — Sat, 03 Sep 2011 08:53:00 GMT

Even though it's September, I started writing this article in late August, so technically this is the August article. Not fair ? Ah, the wonders of free choice. For the August article, I wanted to focus on some do's and don'ts of projectplans. As I was...(read more)

Cogito ergo sum (an article on Cognitive Behavorial Therapy)

Paul — Fri, 08 Jul 2011 18:33:00 GMT

For my first article on DirTeam, I decided to focus on a subject that I myself have found extremely useful throughout the past years. Being employed at a mental healthcare institution and of a curious nature, I found myself reading various works of literature...(read more)

Well over six years..

Paul — Thu, 07 Jul 2011 06:21:00 GMT

It's one of those days when I decided to browse through the good ole DirTeam blogs. It happens sometimes, as an urge I cannot resist. One of the articles I noticed was that of Sander Berkouwer, musing happily upon his five years as a blogger. Curious,...(read more)

The myth of the ICT-professional

Paul — Sat, 10 May 2008 00:07:00 GMT

With a pointedly 'Do you know which month it is ?', Sander reminded me that it was time for another blogpost. Not that I had forgotten, but the past weeks have been busy enough. That, and I wasn't 100% sure on which to write. Admittedly, an article had been brooding in the back of my mind for some time, but the shape and form had been eluding me for some time now. It's an article that may or may not offend some people while reading it, but quite frankly, I don't care.

So, here it is, my monthly contribution to the world of blogging..

Introduction

Lately, I've received quite a few job-offers. Once every while, when you update profiles on websites, the hordes of headhunters seem to spring into attention and jump for the bait. Quite frankly, I've felt tempted to add a PhD, Master-degree and a certification in advanced Yoga to the list, just to see what happens. Who knows.
Every mail I receive seems to contain the sentence 'We're looking for ICT-professionals who... [fillinofferedjobhere]'. At first, this seemed flattering. 'Look at me', I thought, 'I'm an ICT-professional'. A bit of pride swelled up inside of me, and I'd have to take a quick nap to make the feeling go away.

Then, one day, I was browsing through a few profiles on LinkedIn and their connections, and I didn't feel so special anymore. It seems that everyone is an ICT-professional these days. People who answer the phone at a call-center at your local DIY-computershop have now been named 'Customer Experience Management Professional'. Keith, the guy who waters the plants in your office, is now a Climate Management Professional.
And for the job roles that you possibly couldn't match with anything like 'Management' or 'Professional', we'll just have our wicked way with the term 'Consultant'. Everybody wants to feel special. The result is that everyone is now so special, that it's not too special anymore.

Classification

So what makes someone an ICT-professional ? Well, judging from the enormous selection of titles on vacancy-sites and such, moving your little home-PC from the cellar to your new study would just about do it. If you also manage to install a wireless router (consulting the manual is optional, but probably earns you the title 'Jr'), you're just fit about to be a consultant.
The only conclusion that I can draw from this that the term ICT-professional has been completely and utterly raped. It may be just my humble opinion, but having worked at an ICT-call center for three months, patching through customers to in-house technical specialists, does not make you an ICT-professional. It makes you a secretary, and you deserve a cuddle from your boss and a bouquet of flowers once a year at Secretary Apprecation Day.

But, let us for the sake of argument, classify an ICT-professional as someone who earns their living by performing ICT-related duties on a somewhat daily basis. I fully realise that this puts the true technical specialists on the same heap as Bob the one-day fly system administrator who couldn't open up a PC to save his life, but it seems that the job market has made it so.

Distinction

However, if we do that, how do we distinguish between aforementioned Bob and a technical expert ? Surely, I hear the masses cry 'Certifications!'. Ah. Yes. Certifications.
Let us have a look at those certicifations, shall we ?
A few days ago, I enjoyed a nice dinner in Eindhoven (where I live) with a group of co-workers. A part of the group had just attained the MCP-certification, another part of the group had earned themselves the chance to try again, and yet another part of the group consisted of general hangers-on (including myself and blogmeister Sander Berkouwer). As the formal spokesperson of all things Microsoft-related at our company, Sander made a short speech to rally the spirits into more development, search for wisdom and ambition. After the applause had died away, I too delivered a short speech, in which I stated that certifications were all nice and well, but did not determine if you're any good at your job. (One of the lads who had failed to pass the exam works for me at a customer, and does a great job, regardless of the MCP-shaped hole in his resume).
This little statement did not fall well with one of the accountmanagers present, who asked me if I thought that was a smart thing to say. I was happy to respond that, yes, I thought it was. I explained to him that I believe that letting people pursue certifications just to get the certifications is not a true worthwhile goal. As an example, I described an excellent servicemanager with extensive knowledge and experience in the field of ITIL and making things happen, who was forced to pass his MCSA as part of his yearly evaluation. As he rarely got into the nitty-gritty of servers, he had a particular tough time attaining this certification. This, I pointed out, was a perfect example of the 'Get them papers even if you don't need them'-mentality that seems to thrive in ICT-companies these days.
'But surely certifications are also meant to display your knowledge and capabilities in a field of expertise ?', he replied. My only response to that was the example of the paper-MCSE, a symptom that was suffered greatly during the Windows NT4 period, in which any complete twit could pass the NT4 exams with flying colours without even ever having touched a server. To this day, I believe that certifications are very poor indications of knowledge and experience; it only shows you either knew enough theoretical information on the morning of your exam, or that you were lucky enough to guess the correct answers.

Let us also not forget the excellent technical experts amongst us who could pass all MCSE-examens in less than a day's work, if only a) their boss would pay for it or b) they'd be bothered.

Don't get me wrong, I am not saying that certifications are pointless, but they are completely useless in determining a person's capabilities.If you're not convinced, have a look at the Certified Novell Sales Exams 2008 and get yourself a Novell-certification with no effort whatsoever. Go ahead. I dare ya.

Experience

So, if certifications are not a viable option to determine one's worth as an ICT-professional, what is ? Surely experience must provide a way out ?
True, experience gives away more than certification, but there is a catch. How is experience displayed ? Through resumes. A piece of paper. Written and judged by the same person who tries to sell himself to the world. Well, there is definitely a bit of a catch there, isn't it ? Ever seen a truly objective resume ? If you have, please frame it and hang it on the wall, because they are truly rare. Why, I fondly remember my time as an Interior Maintenance Professional, during which period I was personally responsible for the customer experience of over 500+ students, striving to perfect all bathroom-, hallways- and floral experience while not neglecting the wishes of 20+ employees whose joy of work solely depended on my performance! (This little example of resume-decoration refers to the time when I got to work at 6 in the morning to wipe the floors, clean the bathrooms and extract rather dried-up pieces of gum from underneath desks at a local university..)
When I conducted an interview at a customer to determine a candidate's suitability for the vacancy of systemadministrator, I first read his resume which looked impressive. Knowledge and experience with security appliances, management of a servicedesk, extensive systemadministration-skills..
At the interview, it turned out that the resume had neglected to mention that the 'security appliances' was a small Soho-firewall he had set up at home (once), managing the servicedesk consisted of getting in on time in the mornings so he could answer the one phone that the ICT-department had and his system administration-skills boiled down to double-clicking a script that reset several services on a server (a script written by someone who had left the company years ago). Candidate denied.

Talk the talk, walk the walk

Once again, let us make an assumption for the sake of argument. Bob is a candidate for the job of technical consultant at your company. Bob passed his certifications because he found the exams a challenge, and he passed them because of studying hard and having massive experience in the curriculum. Bob also doesn't know how to lie, so his resume truly displays what his career has looked like so far. Bob seems, in every way, the perfect match!

Then Bob comes in. He can't seem to take his eyes off the floor, looks like a big runny egg on legs dressed in an oversized parka, has the charisma of a piece of roadkill and when, by chance, his eyes do meet yours, you have trouble resisting shaking him while shouting 'Make some human contact, curse you!!'. Yep. Bob's definitely perfect for the job.. provided you put him in a dark room somewhere with a lot of TFT-screens and toss some food inside every once in a while. He won't join anyone for lunch, because in his breaks he's rewriting mathematical algorithms for fun. When it comes down to it, Bob is a complete and utter stereotype nerd. Even though he'll do his work just fine, it's impossible to send Bob to any customer.

Thankfully, the clever people who write job advertisements have circumvented this possibility by stating that candidates need to have excellent social skills.. yeah. Right.

Appreciation

Of course, HR-departments throughout time have understood that measuring and appreciating people is a complex matter, and a solution was found. Using lists of levels and competencies, ICT-professionals are swiftly classified by using criteria such as 'Must have a pro-active attitude towards commercial opportunities at customers' and 'Is capable to establish social contact between co-workers easily'. Apparently, the clever people at HR seem to think that a person can be judged solely by numbers and standard classifications, which is, of course, a load of nonsense. I've met plenty of excellent people who, because of these criteria, never got further in the direction they wanted because they lacked (sometimes by choice) the qualification for some of the criteria. Only the reincarnation of Mother Theresa, after years and years of training and practice in the field of IT, management and psychology, could perhaps hope to ever comply with these ridiculous demands.

Conclusion

As some of you may know, I study musictheory in my spare time, hoping to become a better composer of music. A little while, I read an interview with a composer who stated that anyone who had not graduated from the conservatory is not a true composer or musician. Oddly enough, I've played with many excellent musicians who couldn't even read a sheet of music. In his world, these people should not be allowed near a musical instrument; yet, even though they knew nothing of theory, had no certification, never passed exams that said 'Hey, you're a musician!', they played with a feeling and passion that would shame even the most avid graduated musician.

Personally, I feel that there is only one way to truly judge a person's qualification for their job, and that is the judgement of their peers. In the same ways that musicians recognize fellow musicians and their skills, people in ICT recognize the skills in their peers. It's not unthinkable that a group of experienced ICT-consultants would gladly choose someone as their colleague who doesn't possess the slightest certification or even has a career in ICT on their resume, just because they've all seem him or her at work. This person, however, could only hope to be given a chance of becoming a call-center support employee if the industry itself had any say in it.

The greatest appreciation is a pat on the back by someone you look up to, a fellow administrator, developer or architect (let's just use the real terms, shall we, instead of titles that consist of five words with four syllables each), saying 'Great job!' and mean it. Only a peer can judge your worth, and the bigger the group of peers, the more accurate the judgement will be.

Now, if you will excuse me, all this ranting has made me thirsty, and it's time to contact my local Beverage Distribution Management Center and make some coffee..

PS: If you've actually read this entire rant to the end, you might get the impression that I believe myself to be an expert on ICT. I don't. I do, however, get fed up with complicated, meaningless titles, ridiculous methods of trying to ascertain one's skills and other ways to insult the complexity of the human mind. I've seen plenty of it throughout the years and it just seems to get worse now that ICT begins to take an even more prominent role in our everyday lives. There is no such thing as 'The ICT-professional', because that'd require the existence of a perfect, serene person who has complete control over their emotions at all times, while having studied every single scrap of information on every aspect of ICT ever, who is also fun to be around, trustworthy and all those other things we appreciate in other human beings.
It seems, however, that with the ICT-hype taking off again full flight, that a lot of people think themselves to be just a bit more than they are, simply because the sign by their office door has to have two lines to display their full title. Not to mention the presence of no less than two real plants in their office, watered by Bob, the Senior Floral Management Executive on a day-to-day basis..(Keith, mentioned earlier in this post, has become a gardener at the local park and is quite content with it).

Plans and planning techniques: Critical Path

Paul — Sat, 05 Apr 2008 00:21:00 GMT

It's April, so that means it's time for a new blogpost! This time, I've decided to dig a little deeper into the technical aspects of projectmanagement and write an article on planning techniques. We'll examine the various popular methods of planning projects and see what makes them tick.

But first..

It is important to realize that planning is not always mandatory. As I described in my previous article "Paper, scissor, rock", it's easy to get lost in paper, especially when you plan things just to plan them. When you do start planning, ask yourself first whether or not creating a detailed plan and breakdown really, really contributes anything to the project.. don't become a paper tiger!

The various plans

There are many levels of planning that can be done. When we look at a method such as Prince2, we'll discover that there are projectplans, stageplans and teamplans. For every individual section of the project, a planning can be made. At times, it can be useful to create a teamplan (a detailed planning for one team during that phase). However, that teamplan does not need to appear in the same detail in the projectplan; after all, with a large project, this would only clutter the transparency of the projectplan.

Then we have the plans for the various aspects of a project, such as:

Communication plan: A plan that describes what, how and when communication is done throughout the lifecycle of a project.
Quality plan: This plan describes how we ensure the quality of the project.
Risk plan: A plan that deals with risks and the management of these risks.

Oh, so many plans... as the saying goes: "Too many clowns, not enough circuses". It's enough to drive anyone insane! Thankfully, it's not necessary to deal with all these plans in detail. Sometimes, we can leave out some of these plans, or just write them down on the back of a beercoaster as a reminder (if, like me, you prefer doing your creative thinking in a bar).

For now, we're going to ignore the communication plan, quality plan, etc. and merely look at the planning of activities. Believe me, it's enough to begin with.

As a start, we'll examine two fundamental approaches to breaking down a plan into little pieces.

Product-based or work-based

A projectplan will always have a goal. This goal could be the constructing of a new factory, implementing a new productline, moving offices, etc. Depending on the goal of the project, one out of two structures will be preferable. Let's have a look at these structures:

PBS (Product Breakdown Structure): Prince2, as a method, is product-driven. This means that the project is broken down into several 'products', such as 'a new factory', 'a new pair of pants', etc. Following the train of thought that we are aiming to complete various products, we can break down these products in little subproducts. Again, we can break these subproducts down even further, until we reach a level of detail that may seem ridiculous; it's probably time to stop at this point.

An example: Say that we are going to have breakfast. We've been out the night before, and as the hangover plays merry hell with your brain, you decide to be precise in your breakfast (or perhaps you just have too much time on your hands) and plan the creation of breakfast. The main product of this project would be easy: Breakfast.
So, what is this product 'breakfast' made up of ? Well, there'll be coffee. And scrambled eggs. Some orange juice, perhaps. I'm sure you can let your mind wander and think up something. Already, we have three subproducts, being 'coffee', 'scrambled eggs' and 'orange juice'. Again, we can perform this little procedure, and break down these products even further. 'Coffee' becomes 'coffee', 'mug', 'spoon', 'sugar', 'milk'. 'Orange juice' becomes 'glass', 'oranges', 'juice machine', etc.

I'm sure you see where this is heading, and that it is easy to get lost in details too soon. Try to remember that a planning is supposed to help you control and schedule your products, not demonstrate your intense knowledge of how to make a good breakfast, shall we ?

Then there is a more popular method, which is activity-based:

WBS (Work Breakdown Structure): Contrary to PBS, WBS defines a project as 'a lot of activities that have to be done to achieve something'. So, instead of defining products, we define activities. Just as with PBS, we can then break these activities down into subactivities. So, instead of the product 'breakfast', we could define the activity 'make breakfast', which contains 'scramble eggs', 'pour coffee', etc. I'm sure your creative mind can break down the above breakfast-example even further.

Even though these structures seem rather similar, they will give different results and therefore, different planning. Try for yourself and see!

Now that we have examined the structures available to us, let's see how we proceed. Let's assume that we used PBS to breakdown our little breakfast-project. Below, you can see how a planning like that would look (that is, if I manage to find the right buttons on this blog to upload a picture...):

Ah! Success! OK, so it's slightly oddly sized at the moment, but I'll fix that later..

There are a few things that one would notice from this planning. First of all, there's the fact that all activities seem to take the same time. This, of course, is nonsense, but right now, I don't feel like putting in any times. Not yet.
Second, and very important, are the sequence in which the activities take place. Apparently, we are able to scramble eggs, make coffee and make orange juice at the same time. However, let's keep in mind that we're still hungover, so multi-tasking is out! For the sake of argument, let's presume we can only make coffee and orange juice at the same time. For the scrambled eggs, we need our fullest attention. Also, as we only have one electrical socket, we'll have to choose: Bake eggs first (let's assume that your stove is electrical) or make coffee first ? As it's nice to have a cup of coffee while baking, let's start with the coffee first. In the meantime, we'll make orange juice, which doesn't take as long as the coffee. Our planning will change:

Note: No, it doesn't take me several days to make breakfast, but for the visibility in the Gantt-chart, it's easier to use days, instead having to alter all the taskdurations and tell Project 2007 to use hours. Sue me, I'm lazy. Also, I altered the task-layout to create a more readable Gantt-Chart, as you may see.

As you can see, there is a clear path that is walked through to achieve our great project 'Breakfast'. It is this path that I want to touch upon now, because it's a very important part of planning. Can you guess ? Yes! It's called 'the critical path'.

The critical path is a chain of tasks that has to be completed in order to achieve projectsuccess. In this case, we need coffee, orange juice and scrambled eggs to enjoy a good breakfast. Notice that in the example the product 'orange juice' does not have a direct impact on the other tasks. As the tasks themselves also take a lot shorter than the other tasks, we do not need to focus directly on this task. Only when there is an extreme delay in this task (perhaps you still have to grow the oranges) will the project's end date become affected. The activity is in the critical chain, but there is a lot of margin for delay in this task.

The other two tasks, however, need more attention. Any delay in the coffee-making will also have a direct impact on our scrambled eggs. As it is early morning, the chance that you forget to turn on the coffeemachine and get into the juice-making is very likely. As a result, the task of making coffee will take more time, the scrambled eggs will be prepared later than planned and by the time we've finished making breakfast, it'll be time for dinner.

Network diagrams

A planning like I've put up above is all nice and well, but to determine the critical path, it's common practice to use so-called network diagrams. These diagrams represent all the activities in network layout, making it easier to determine the critical path of a project.

I won't go into the two different types of network diagrams common to the CPM (Critical Path Method), but suffice to say that I'll be using an extremely basic AON-diagram (Activity On Node) instead of the AOA-diagram (Activity On Arrow) as the former is less prone to error than the latter (if anyone's interested, I'll write on article that goes deeper into CPM for next month).

Below is a very basic AON-diagram for our little breakfast-project:

The various circles (or nodes) represent activities. In this case, the following representation is used:

A: Turn on coffeemachine

B: Pour coffee

C: Scramble eggs

D: Squeeze oranges

E: Pour orangejuice

F: Serve breakfast

Suffice to say that this is a very basic representation of all the activities in our little project; however, it'll do to bring across the basic idea of a network diagram. Represented visually, it's a lot easier to perceive that the activities A, B and C need to be performed in sequential order to get to serving breakfast. Also, activities D and E are done in sequential order, but parallel to A, B and C. However, to get to F (serving breakfast) we'll have to go through the entire network to achieve projectsuccess.

Note: A network diagram is more often a lot more complex and though-out than this one, and there are a lot more details to consider. These are related to network routes, predecessors, weights, etc. Again, if there is enough interest to go into detail on this, I'll write an article on it.

Conclusion

There are various conclusions to be drawn from this article. One of them is that planning is not something you do once. Time spent on activities change all the time, and it is necessary to review your planning constantly, or at least very regularly. Whereas planning is iterative and often vague (especially with future events), critical path analysis is (if you do it well) something that needs to be done only once and after that serve as a contineous and invaluable tool. Critical path analysis makes it easier for a projectmanager to determine the priority for teams and their activities by keeping an eye on those activities that impact the critical path and those that don't (in a complex project, there will always be side-chains). Though Gantt-charts (for those unfamiliair with the term, a Gantt-chart is the graphical representation to the right of our little PBS in the first two pictures) can be used to keep an eye on the project's progress, it's often a lot easier to stick to the network diagram instead. One reason for this is that in a Gantt-chart, a simple activity may seem like a little thing that can be done in an hour, while in a network diagram this activity will be seen as an important junction in the critical path. Especially with complex projects, it's easy to miss an activity in Gantt-charts or breakdowns.

There is also another important aspect of critical path analysis, which is the improvements and 'out of the box thinking' the critical path often bring forth. In our little breakfast-project, we've placed the coffee-making and scrambling of eggs in sequential order. Doing so has had a direct impact on the critical path, prolonging the duration of the project. In our network diagram, we notice a sequence of activities that have to be completed before we reach that final node F; serving breakfast. By examination of the network diagram, we might be triggered to suggest the installation of an extra electrical socket, allowing us to place some activities in parallel order; by doing so, we'll allow future projects to be finished swifter. This is more visible in the network diagram than it is in the Gantt-chart. Another wonderful aspect of network diagrams and critical path analysis!

By managing your projectplanning through the use of critical path, you're more likely to complete your project on time and within budge by focusing on what matters.