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).
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.
Documenting your project is a wonderful thing. It can fill those lonely hours that you'd normally spend behind the geraniums watching the rain drizzle down in a slightly insulting manner. It can warm your heart as it grows in size and keep you company at seven in the evening, your office being the only one still occupied in the building.
There are many reasons to love documents, but there are also some to fear it. In this article, I'll be discussing cons and pros of documentation. We'll see when it's time to choose paper, scissor or, sometimes, the rock.
'Prrrrrr'
'Prrrr' is the sound of the paper tiger. It's a lonely animal, and scared of changes, faults and the randomness of real life. The paper tiger writes documents because he can. Every tiny bit of the project is put down to paper in the most extreme detail. Even visits to the toilet or funerals of grandmothers are anticipated. The paper tiger is one to fear, as he (or she) may very well whap you to death with the enormous bulk of pointless writing that looms on his (or her) desk.
What on Earth may drive a projectmanager to be so extreme in documentation ? That question is easily answered: Fear. Fear of failure. Fear that, at some point, somebody will turn around, waving an accusing finger and shout: 'You have failed us all!'. The paper tiger will try to cover his or her behind with bits of paper, and will therefore document everything that could possibly be documented.
Needless to say, a paper tiger is a very dangerous creature to have in your midst. Their minds will be completely focused on writing documents, and anything that is not documented will be a great and terrible danger that must be avoided. This has many downsides. Let's have a look at these downsides:
- Writing all the documentation will cost valuable time that should be spent on managing the real projectactivities and the project's teammembers. A paper tiger will rarely spend much time on these activities, because most of them are not paper-related. As a result, the paper tiger will not notice that a certain teammember becomes less and less motivated for whatever reason. By the time that this projectmember has accepted a new position at another company during the project, the paper tiger will be searching very hard in his (or her) risk log to see if this event was documented. If it wasn't, you can be sure it will be from now on.
- Any definition of a project will have the word 'dynamic' in it. Projects are always of a dynamic nature. They are subject to real life, are not part of the daily activities and therefore, well, anything can happen. Trying to capture all this 'anything' in documents is an endless chase. Because of this, the further the project advances, the more the paper tiger will be focusing on the set path that the paper has laid out for him. As a result, the paper tiger will not be able to follow one of the golden rules of projectmanagement: 'Managing a project is not about following the projectplan to the letter, but about achieving the desired result in a set time and budget.' Any chance that will occur to achieve this result earlier, but is not documented in the projectplans, will not be noticed by the paper tiger. After all, it's not in the documentation.
- Paper tigers are, often, a laughing stock. Their obsession with paper, ridiculous details and fear of change will be noticed by projectmembers and boardmembers alike, making his or her position merely a formal matter; informally, everyone connected to the project is likely to take care of matters between themselves, without having to route it past the paper tiger; after all, he (or she) will just delay progress by having to nail everything down to paper.
If anything, the paper tiger is to be feared and avoided.. and pitied. A chain is only so strong as its weakest link, and if the weakest link is the projectmanager, you can rest assured that it will be a very, very weak chain indeed.
There is, of course, one advantage to the paper tiger; you can rest assured that every little detail is discussed, covered and written down. Especially with complex projects, this can be a very fortunate advantage.
Snip snip
When writing projectdocumentation, I have found it wise to consider thoroughly what should and what should not be documented. Applying scissors to the masses of templates and suggestions available in projectmanagement-world, you can end up with a usable pile of paper without having to preening your paper fur.
So what should definitely be documented ? Well, let's have a look at some points that I'd personally never skip.
- Goal: Not putting a project's goal to black on white is a hanging offense. When the project is finished, eyes will always turn to this bit of paper where it is described what exactly we wanted to achieve with this project. The project's goal is the very reason of existence for a project and should never be forgotten. It should also be discussed extensively with all parties concerned, so that there is no misunderstanding about what the project should make possible. When a project has a goal described as such: 'Enabling communication through e-mail for the entire company', it's most wise to sit down with the person hiring you and discuss exactly what that means. Hey, perhaps you could just place one workstation with a dial-up connection to AOL and be done with it; after all, the project's goal is achieved... but it's quite likely that that was not what the projectboard had in mind, when you're talking about a company with 2.500 employes..
When describing the project's goal, avoid all possibilities of interpretation. Be clear, short but complete. - Results: Contrary to popular belief, a project's goal and it's results are not the same thing. True, they are often closely intertwined (see the above example about e-mail), but they are rarely the exact same thing. Keep in mind that the project's results are those deliverables that enable the company to achieve their goal through exploitation of the results. Again, be clear, short but complete. If you're not, it will never be clear when the project is really finished, causing it to drag on forever while people naggle over the definition of a certain result. By then, you'll be way over budget and over time, wishing you had just defined one of the results as '250 workstations with application A on them' instead of 'All relevant workstations installed with application A'. You will be amazed how long people can argue over the definition of 'relevant'..
- Budget and resources: Describing your budget and required resources is important. It's possible to skip this step sometimes, but personally I like to include it; it's always good to make people understand what resources (monetary and otherwise) you need to achieve the results. Resist the temptation to be too specific, however. Most projects will have little set-backs that will require more resources. They might, however, also have little moments of good luck, in which activity X costs less than thought at first. If you define the budget to activitity-level, a projectboard is likely to think 'Oh, good, the project's going to cost less now', even though you might need that little bit of luck to make up for a set-back in activity Y. Managing the budget is your responsibility, so make sure you have the freedom to alter it when required, as long as you stay in the agreed thresholds.
- Planning: Need I say more ? Everybody wants to know what will be done when, and when the project is planned to be finished. Again, be prepared to alter the planning when necessary. Planning is always volatile. Accept it.
- Risks&Issues: This one should go without saying. Sometimes, you'll be able to just keep a small list on a Post-It, and sometimes you might need to administer a detailed list.
Even some of the bullets mentioned above can be discarded at times, or merely communicated orally. There are no strict rules to projectmanagement, despite what people may try to tell you.
Rock on!
There will be times when you need to be rigid as a rock, and insist on discussing issues that people don't want to talk about. These are often the political issues, the glass houses in which people have housed themselves throughout the years. Be prepared to do some damage to these houses occassionaly; if you don't, you may find some nasty surprises along the way when the skeletons come falling out of the closets. Don't let somebody else's problems become yours because you didn't have the guts the focus on the painful spots and memories of an organisation.
Paper, scissor or rock.. ?
Deciding which of these items you need to be can be difficult. In the end, it is your responsibility to deliver the results required for a company to achieve the goal they set for the project. You will need to bend, twist, break and sometimes jump; as long as it gets the job done.
.. be warned. As of today, I've decided to make at least one blogpost every month. I was reminded by the fact that I still _have_ a blog by Sander (and indirectly by Carlos. Hi Carlos!) and he kept hugging and cuddling me until I caved. I tried to run, dodge and jump out of the window, but as it was closed (and closed firmly) I saw no other option but to give into his desires. Well. Some of his desires. Perv.
The posts in question will, however, have very little to do with technical stuff. These days, it's considered a environmental hazard to let me anywhere near technology (the Christmas-present we got from the company this year, a 180 GB LaCie external harddrive, died two days after I got it, merely by looking at it). So. If something else than technology is also your cup of tea, you'll find a new post here every month.
Blame Sander. I know I do.
A few weeks ago, I got a call from one of our accountmanagers. If I would be available to perform a migration at a customer. The situation seemed a bit tricky, as the customer had a clusterconfiguration that, apparently, 'wasn't very stable'. That, it turned out, was a euphemism..
Upon arrival, I logged onto the servers and examined the situation. It seemed that everything that God and Bill Gates had dictated had been completely put aside in the name of clustering; Let me draw you a verbal picture:
Both clusternodes were configured as domain controllers, with all the little bits and extras you could imagine. Exchange 2003 was also placed in the clusterconfiguration. But wait, that's just the beginning! Apart from this already hideous configuration, whoever had created this configuration had also decided that it would be an excellent idea to place BackupExec, SQL Server 2000 and file- and printservices on the nodes. And, to finish it off, there were at least 10 little tools and tweaks in place on every node; in short, it was a complete technical nightmare. Oh, and did I mention that the two nodes were moved out of the Domain Controllers OU, most likely because the DDC policy made the machines too restricted ? I probably didn't; well, the DCs were moved out of the Domain Controllers OU. Oh yay. Oh, and did I mention that SQL Server 2000 was only installed on the first node and that the SQL resource was configured to remain on that node ? Yeah, that's what I call a benefit of clustering your resources..
We started with putting a shiny new DC in place, made all the servers a GC (naturally, only the first node was a GC _and_ held all the FSMO roles..) and then moved the FSMO roles to the new machine. Guess what ? The cluster crashed. Completely. Surprised ? I wasn't. A quick scan around the Event Log and the Services MMC quickly pointed me to the Network account that lacked access to the DTC; KB article 923977 very swiftly yielded the solution, and cluster failovers were once again possible.
Then, a temporary Exchange 2003 SP2 server was put in place. This, thankfully, didn't pose any problems... yet.
On Friday, the mailbox migration process was started. As quite a few people had mailboxes well over 3 GB in size, this took quite a while.. after that, System Folders and Public Folders were rehomed, routing connectors were adjusted, the RUS was rehomed, and things seemed fine.
De-installing Exchange from the cluster didn't go flawless; quite a few errors regarding missing installation files made it a rather hellish process (people who make temporary drive mappings for installation that point to completely illogical and non-existing datashares should be shot on sight), but with some fiddling, we managed to remove the cluster resource and software.
And then, the moment of truth. Time to demote the cluster nodes and see what happens. Can you guess ? Yes, the cluster went berserk. Services, failover, everything completely crumbled. Once again, the DTC fix mentioned earlier saved the day; it makes you wonder why exactly Microsoft declared this to be a unsupported configuration. I have _no_ idea..
Thankfully, we managed to tackle the situation and very soon, we had two stable cluster nodes. Exchange was reinstalled, public folders and system folders rehomed, and as I write this, the mailboxes are moving back from the temporary server to the cluster.
As a temporary fix, I've had to place secondary DNS-zones on the cluster.. wanna guess why ? Come on. Guess! Yes, because the Nokia Checkpoint that acts as firewall and VPN-server is a complete and utter mess.. Of course, a company with 40 users definitely needs a Nokia Checkpoint. It wouldn't do, for example, to place a PIX515e or an ISA Server for that matter. That'd be too cheap and too easy!
Service accounts, freeware tools, completely modified ACLs, a cluster that should, by all common sense, have collapsed years ago and general incompetence.. just the thing to have to clean up on a Saturday..
We all know that it is vital to protect our systems from viruses and outside intruders. If we fail to do so, our beloved systems are very likely to end up as nodes in a botnet, have their contents read and altered; you name it. So, to prevent that from happening, we install virusscanners and firewalls, trusting in the fact that this will save us from eternal digital damnation. But do we know how these applications save us from our disastrous fate ? Perhaps you do, perhaps you don't. If you do, feel free to read on and correct me on any gaps. If you don't, well, also read on and allow me to shed some light on the wondrous world of security.
Viruses
Everything in a computer, be it hard- or software, is made by human hands. Though it isn't possible for a logical system to make a mistake, in practice such a system is still the end-result of human engineering and to err is human. A typo in code, a subroutine that is badly written and provides access to subsystems through global parameters; the options are endless.
People who makes viruses know this. To be more precise, they thrive on it. Using their technical skills (I am NOT counting scriptkiddies, these should be given a whack on the wrist and sent home to mommy), they create an often very simple little program called a virus. This virus abuses errors in (most often) software to give the maker access to systems he or she wasn't supposed to have access to. Often, these viruses open up little backdoors for their maker to gain control of the system (a concept often used in botnets).
Thankfully, there are also good people in this world and they all make virusscanners. We all know that there are various forms of scanners, ranging from high-end to consumerlevel. They all have their benefits and downsides. Some are expensive, others are hell to use. But, quite frankly, the most important aspect of these programs (in my not so humble opinion) is: updates.
You see, while people who make viruses strife to abuse errors in code, people who make virusscanners strife to protect your system. They do this by using virus signatures. This can be best defined as a fingerprint of the virus. This fingerprint is often a unique binary pattern associated with the virus. It can be the specific code that abuses the errors in the system, or it can be the trademark of the virus. For example, a few years ago the digital world was cruelly ravaged up the proverbial behind by the I Love You virus. This virus, containing a Visual Basic script, spread itself throughout the world in a tempo that had rarely been seen before, abusing a weakness in Microsoft Outlook. Various international companies were struck by this, causing productivity in certain areas to fall to completely zero for a while.
The signature for this virus isn't very hard to guess; the title. The virus spread itself through an e-mail, containing an attachment, with the title of the mail being: I Love You. The makers of virusscanners swiftly reacted to this by adding a virus definition to their software, using the 'I Love You'-subject as a signature.
Of course, not all companies reacted to this immediately. As the maker of a virusscanner provides its users with a new definition database every once in a while, it's a pretty tricky situation if the company that provides your free, shiny and simple virusscanner doesn't update its definitions for another month. In the world of Internet and viruses, a month is a very, very long time..
Application layer filtering
Naturally, there are other ways to gain access to a remote system. Many protocols and programs throughout time have had a certain vulnerability in their code that provided an outside attacker with the means to gain remote control. For example, in IIS 5.0 on Windows 2000 it was possible for an outside attacker to cause a buffer overflow by sending an overly large packet to the .printer ISAPI. It may, or may not, surprise you that an OS like Windows (and for that matter, any other application and OS) often contains many of these 'bugs'; if it's built by human hands, there will always be an error somewhere, you can count on that.
Whereas 'older' firewall-software only filtered traffic based on, for example, IP addresses and ports, modern firewalls have expanded their repertoire to the data sent and received itself (the application layer). While the data passes through the firewall application, an application layer filter inspects the traffic to ensure that no malicious code is inserted into the data. If a deviation is found, the TCP connection is immediately broken down before it leaves the firewall (known as in-line scanning). A variation is that the data passes through the firewall but also takes the normal path to the system. Therefore, the traffic will reach both the host and the firewall. The firewallsystem will reset the connection but will be too late, as the traffic has also reached the host already (known as promiscious scanning). The first form is also known as IPS (Intrusion Prevention System), the latter is known as IDS (Intrusion Detection System). The better your firewall, the more advanced it will be in the area of IPS/IDS and application layer filtering. Microsoft ISA Server, for example, provides various mechanisms in this area. Your ZoneAlarm Personal edition from, say, 2003, will be less adequate..
So why doesn't everyone just use the best possible firewall- and virussoftware ?!
Easy. The best solutions are a) more expensive b) often harder to configure and c) require a good understanding of exactly what is going on and what the impact of a situation might be. A sysadmin at a multinational is more likely to employ the best solutions than your 70-year old aunt who can barely find the Power-button on her PC.
Conclusion
As technology advances, the complexity of threats also progresses. Every day, new viruses are created and fresh, shiny bugs are found and exploited. If you value your system and the data on it, and would like not be prosecuted for being part of a botnet that launches a full-scale attack on, say, the Pentagon, you'll want to keep up to date. Not just in the technical sense of advanced software, but also on the practical side of security. It is, in this area of computer science, always better to be safe than sorry, even if that might mean you'll have to put some more effort into securing your system and/or using it. Believe me, it's worth it.
Resulting from a small scenario I handled today at a customer, I wrote a short post on ISA server client requests and why it doesn't always 'just work'.
You can find it here:
http://blogs.dirteam.com/blogs/paul/pages/no-it-doesn-t-do-that.aspx
Enjoy!
Paul
When you look at it, planning makes a project go round. It defines the lifespan, control and scheduling of all activities. And when we're being honest, that's what projectmanagement (in it's technical terms) is all about.
Still, even planning is a subjective matter. After all, a planning is nothing more than the expectations of one person (or, when well thought out, that of several). What a planning basically says is: "We expect this activity to take X hours, using X resources, costing X <fillinpreferredcurrencyhere>".
There are various approaches to planning. Some of them are more reliable than others, but most of the time, you don't have the luxury, time or opportunity to choose. Let's take a look at some of the approaches available to us, shall we ?
The 'Easy Peasy!'-method
The Easy-Peasy-method is one of the trickiest forms of planning. When using this method, somebody on your team says 'Oh, I can do that! Easy! Just gimme an hour and it's done.'. As you have no reason to distrust your teammembers, you plan one hour (two, to be on the safe side) for the specified activity. In most cases, this might work out fine. However, keep in mind that the task at hand might not be so easy-peasy after all, and what you planned to take two hours might take two days. Deadlines woosh by, agreements are broken and Hell breaks loose. With added Hell-ness.
Is there a way to prevent this ? Of course there is. Ask questions. A lot. When somebody says 'Oh, I can do that! Easy!', then feel free to ask 'Really ? And how would you do it ? In small, specified steps ?'. Often, you will find out that people make assumptions that may or may not be valid. Try to locate these assumptions, test them and soon you'll discover that 'Easy Peasy' only exists in a world where the Tooth Fairy exists, politicians are honest and where everybody really wants to get along with everyone else.
The 'I Don't Want To Commit'-method
Some people seem to excel at not making any commitment. When confronted with the horrible question of 'When might this be ready ?', they summon a fog as thick as peasoup, scatter arguments like 'presuming that X does Y and not Z' and suddenly seem very anxious to visit the bathroom. Anything not to commit to any form of deadline.
This, I believe, is a good thing. It shows that whoever is doing the job is aware of the fact that in a project, things hardly ever go as planned. However, there is such a thing as too much caution. Basically, the easiest way to plan this way is to say 'Alrighty, let's take two weeks for it then', watch people object and up the planning by a few weeks. Make sure that all risks are well documented and remind people that a planning is always an estimate. Nobody's going to beat you to death when the team fails to meet a planning as long as you've documented risks and dependencies.
The 'We've done this before'-method
Now this is definitely a great method. As you may be aware, most organisations have a projectmanagement office that keeps track of all projects that have passed in the company. These records may contain Lessons Learned reports, old plannings, project plans, quality criteria, etc, etc. If you have the luxury of such an organisation, read the records. All of them. Use the collective wisdom in those documents, as it is very likely that everything that happened in those projects will also happen to yours. It's Murphy's Law, but with a rowdy attitude after a good night out in town. It doesn't like you and will definitely kick you when you're down.
Plannings based on these methods are often the most accurate. They're based on experience, past failures and success, and collective wisdom. The only downside is that very few organisations have such a projectmanagement office. Oh, surely, they have the people. It's all there on paper. But every time a new project starts, the wheel is re-invented and the smeg starts over again.
Conclusion
Plannings are always a subjective matter. Sickness, holidays, personal problems.. anything can make a planning completely derail and head for the gutter. Therefore, be sure to be flexible in plannings. Use common sense, try to think of all the possible scenarios and then, when your imagination has stopped summoning complete disasters.. use the average. Document risks. Ask questions. And for Pete's sake (if Pete is your teammember), don't use plannings as a weapon. A wet newspaper is even more effective than that.
During the past years, I've done quite a few projects. As a techie, I was often extremely annoyed at that which is so lovingly referred to as 'Decision Time'. After all, I was the techie, I said how it was to be done and that's the end of it, right ? Right!
Wrong. Unfortunately, there are many more factors involved in projects and the decisions that come with them. There's the 'Stay Off My Turf'-factor, the 'Awaiting Approval'-factor and the 'Yes, But What Does It Do ?'-factor. Three extremely important events in every project and very often, one of these factors is the reason a project totally and utterly fails. Let's take a closer look at these factors and how we can deal with them.
Stay Off My Turf!
Ah, the joy of starting a new job. The wonders of new challenges. Just imagine all the wonderful things you will achieve! Can you see the amazing new technologies you will introduce to the hungry minds at your customer ? I'm sure you can. However, there might be one or two people who will disagree with you. For example.. well.. everybody.
Most projects start with a mandate given by the managementteam at some level. It is suddenly decided that new technologies are desperately needed to compensate for the organisation's inadequacy of dealing with the streamlining of their everyday processes. So, instead of worrying about that, let's introduce some new technology instead. Hurrah! You're sent for to deliver the customer from damnation and certain doom. Nuts optional.
Fresh and fruity, you start the first day. You talk, you womble around, search for the coffeemachine and get to know all about the new people you'll be working with. Very soon, you discover that some are anxious to see you and some are, for some reason not. But why not ? After all, you will release them from the shackles of ancient technology into the free and wonderful world of modern opportunities!
The problem right there would be that that 'ancient technology' is probably what keeps certain people employed at the customer in the first place. They started administering and building it 20 years ago and have become completely unmissable because of it. Nobody knows how it works, the manual is written in ancient Swahili and the only way to get insight into the system's details is to wear a small strawberry-cake on your head on a clouded Tuesdaynight in November, dance the polka with a chair and sing the lyrics to the Dutch anthem in a falsetto voice. Then, and only then, will the veil of obscurity be lifted somewhat. Not a very likely thing to happen, is there ? And so, the people you need most for information and co-operation will deny you all access to their turf, making your work nearly impossible. When during migration you suddenly crash headlong into some vague batchfile that seems only to set the screensaver's time settings to 5 minutes but is also responsible for the complete flow of data throughout the infrastructure, they snigger and grin evilly from behind the large fence that separates their world from yours and say 'Told you so'.
So how do we deal with that ? A good question. The first and my personal preferred method is to gain their co-operation by making them realise that one way or the other, this change is going to happen and that they could benefit from being involved with the project. Surely, a good techie (or even a mediocre one) can gain sufficient insight in new technology by being involved in the setting up and development of the system itself. Trying to develop their enthusiasm by showing them what the new system can do is also a good approach, but you'll first have to figure out what makes them tick. I've succesfully done so a few times by showing GPOs to the system administrator that was constantly complaining about the enormous scripts of registry settings he had to maintain by hand; sold in second.
Awaiting Approval
So, you've got all the techies involved and eager to get started. Everybody's just dying to get started! So what's keeping them ? Well, approval, of course. Managers are often busy people and finding a slice of time in their schedule in which they can give the approval required can be difficult. To a techie, this is the most frustrating part of all. Why wait ? Isn't it obvious that this is the way to go ? Of course it is.
However, managers also carry the responsibility for projects in their department. If the project turns out to be a complete and utter ***-up, it'll be their behind on the line when they have to explain to senior management that 'Yes, we did spend 300K on a system that didn't turn out to work, but hey, we're all human ey ?'. Therefore, managers like to know what they're getting themselves into and will be reluctant from time to time to give approval to something they haven't checked out in every detail.
Dealing with this one can be easy. Though it takes a bit of time, make sure that you've written a clear and easily understood plan of approach. Outline all the products, methods, risks, benefits and costs until you're so sure that everything's included that you'd bet your life on it. Then, either plan a meeting with the manager in question or just assault him/her at the coffeemachine (preferably around 8 am when they're most vulnerable). Talk through the plan and make sure he/she nods at every line. If, at any point, there is a look of confusion in his/her eyes, immediately grind to a screeching halt and go over that part again until the frown becomes, once again, a nod. Don't make the mistake of ignoring the frown, it'll come to bite you in the ass later on.
But What Does It Do ?
Being able to translate a technical plan into a functional one and back is not easy. Sometimes, it can be impossible to describe the use of, say, a backend database upgrade to people that aren't technical or interested. This will turn into the scenario where you, with all good intent, are confronted with a room of people who say 'Yeah, but what does it do ? What's in it for us ?'. One hour later when you've stopped crying in a corner somewhere, you'll get a pat on the shoulder and hear 'Let us know when you've changed the plan'. If, at this point, you work in an office with a balcony at, say, the 10th floor, resist the temptation to take the easy way out.
Instead, sit down and completely forget about the technical details. And I mean completely. They no longer matter. Then, try to imagine all the things that may come from the project. Does it mean less maintenance time is required ? Do licences change and become cheaper with this new version ? Is there suddenly a way to allow users to administer their own rights instead of having to call the helpdesk and wait two days ? Write them all down. All of them. Accost one or two non-technical people at the coffeemachine (really, you should live there at this stage) and confront them. Examine their reactions and place a priority on all the benefits you've managed to come up with (invent one or two if your options are limited, preferably some that aren't really measurable in the first place) and then place them all in your shiny projectdocument. You'll be surprised at the next meeting. Really.
Conclusion
Naturally, there are many more factors involved in projects and the management of them. But these three are the ones I like most so those are the ones I put in. Hah.
What it all boils down to is.. 'communication'. Ensuring that everyone knows what is going to happen when, why, where and by whom is the vital factor to the success of any project. Don't make the mistake of assuming too much; always check every detail as well as you can, or make sure someone higher up has given written approval of ignoring the detail in question. I realise that that sounds like a rather sneaky thing to do, but quite frankly, that's the way it goes.
If that doesn't sound very appealing to you, then I'd advise you not to take up projectmanagement in any form. ;)
.. this time on Vmware.
I just realised I might have to apologize to the people reading all this. For my work, I do a lot of different things, some of which are not related to Active Directory at all. I have in the past years developed databases, done service and process quality management, etc, etc, and as a result, I also post a lot of stuff that isn't AD-related at all. So you'll have to accept the fact that I blog about everything I find interesting for you to know. ;)
Have fun!
Oops! I completely forgot to mention that this new post is under the new 'Paul on: VMware'-category. Have a look at it.
Time is a valuable thing, and I'm pleased to announce I've managed to create some. As of this week, I'll be working 4 days a week instead of 5. I can afford it, so why not ?
I've added a new general article this evening, and start on a new article tomorrow (yes, on my day off). I have a few ideas that have been on the shelf for some time now, and it's time to take them off, dust them and put them on the web. Hope you enjoy it!
I've added a new post on VPN Quarantine; time to get into some more details!
Paul
I've posted an article that gives a brief introduction to ISA Server's VPN Quarantine Control. Later this week, we'll have a look at the more precise working of this process and how we can use VB scripts, CMAK and the underlying building blocks to make ourselves (and our VPN users, perhaps, but hey, who cares ?) happier!
I've posted an article in the General section on a VMWare pitfall I wanted to share with you all. Read it, learn from it and make sure you don't fall in the same pit.
Regards,
Paul
I've added an article on ITIL implementations in the General category. Enjoy!