Share your knowledge and create a knowledgebase.
Building a better bottom line is just as important for an IT department as it is for the whole organisation at the enterprise level.
Implementing sound financial management within an IT framework is broader than simply being more efficient. Many factors are involved: an understanding of the main drivers of IT costs, aligning IT spending plans with overall business strategy, using financial resources efficiently, viewing IT expenditures as investments and having procedures to track their performance, and implementing sound processes for making IT investment decisions.
Estimating what a project will cost is only half the battle; controlling those costs during the project and after delivery is equally critical. In this article, we examine some methods to predict and manage costs, part of a sound basis for overall IT financial management.
1: Control baseline costs
Nondiscretionary money spent maintaining established IT systems is referred to as baseline costs. These are the "grin and bear [...] Continue Reading…
I recently came across a survey blurb that stated that a certain percentage of management feared being out of the office because they were afraid that a subordinate would outshine them in their absence. While I don’t remember the exact percentage of those respondents, I know it wasn’t a trivial number.
I was a bit shocked by the response because (perhaps naively) the thought never occurs to me when I’m out of the office. The fact that there are managers with this paranoid fear says several things to me about their management difficulties:
1. They are very insecure in their position.
2. They work in a very dog-eat-dog environment.
3. They are afraid of their own subordinates.
4. They probably take credit for everything.
5. They probably never share in the blame.
6. They have low self esteem.
7. They don’t view their marketability as being very high, increasing their fear that they will lose their job.
Perhaps [...] Continue Reading…
As a manager of technical projects teams, I have come to make some generalisations about IT people to help you gain a better understanding of the people in your group.
IT pros:
1. tend to be introverts
An introvert is someone who is more comfortable with an inward focus in life while an extrovert is generally more comfortable with an outward focus. For example, when introverts receive a lot of new information, they tend to want to think for a while before speaking or drawing conclusions. Extroverts, on the other hand, are more comfortable expressing ideas to others. If they jump to the wrong conclusions, they just change their minds. Basically extroverts are comfortable thinking out loud. Introverts would rather think through the "rough drafts" in their minds and then talk when they think they have a coherent and logical position.
2. tend to think more logically than emotionally
This tendency should be obvious. [...] Continue Reading…
I often write about managing others through problems or crises because it’s part of the day-to-day experience as a manager/leader. But what about managing yourself? You’ve probably found yourself at some point faced with a project or task that you have to tackle, but for whatever reason you can’t seem to accomplish it.
Let’s say you’re trying to attain a certification such as your PMP, CPA, or a certification in ITIL or Six Sigma. Many organisations now are asking their managers to get certifications as part of their performance/growth plans and some are tying them to future employment or bonuses, the ability to advance in the organisation, etc. In these situations, only you can learn the information. You can’t pay someone to learn for you (no matter how much you would like to).
So what do you do when you’re faced with a task like this and find that you’re not [...] Continue Reading…
There are two places that scope is defined on your project. High-level scope is defined in your project charter. Low-level scope is defined in your business requirements document.
High-level scope consists of two main components.
1.Deliverables. If you can’t remember anything else about scope, list your deliverables. Defining your deliverables goes a long way toward defining the overall scope of the project.
2.Boundaries. You should also try to define the boundaries of your project. Boundary statements help to separate the things that are applicable to your project from those areas that are out of scope. Examples of boundary statements include:
* This project will affect USA operations only. All other locations are out of scope.
* We will deliver our solution to the Finance and Legal departments. All other departments are out of scope.
Think of project scope as a box. High-level scope defines the sides of the box and separates what is relevant to [...] Continue Reading…