What is it about seriousness at work? Just because we are talking about work, do we need to become serious? Is there something about work being all work and no play?
Somedays, i feel that people need to justify receiving a salary, and so needs to suffer to justify this money and thus should not enjoy themselves - this is definitely something christian here... Otherwise, when people are enjoying themselves, look happy, their boss could imagine they do not need the salary or at least the raise. Is there a secret salary ladder depending on the perceived hardness of the corporate job? Obviously the ladder is inverse to the blue collar one where the most painfull jobs are the least paid....
I can see this as the only reason why so many people feel sad and serious at work? Any other idea anybody?
That could be the only positive output of the current crisis: that people can feel happy to work and not bear bad feelings about it.
Monday, May 4, 2009
Friday, March 27, 2009
Tips for carrier management in IT in a large corporate firm
In those tough times, it is important to keep in mind the basics of carrier management and how-tos for progressing (or staying) in the ladder of large corporations IT departments.
Among the necessary soft skills: learn to never report bad news. You are paid to make your boss feel good, not to give people additional work! At the same time, someone needs to get the work done, make sure you don’t do too much so that you have time left, for instance to plan for your future carrier. There are some more soft skills you do need to master if you want to move up the ladder, remind me of them.
Some ideas to progress in the ladder: do not belittle! What is the use to simplify the IS of your firm? You will end up with less staff and less issues! Think long term: propose to add layers of IT so that you add sexy (sexy not useful) functionality…and more staff (yes, you can be a big boss too), so that later you might have more production problems (yes, you are important) requiring additional expert staff and raising architecture questions (yes you are an expert). We all have numerous stories about making boss the one who created the mess…
One of the best ways to achieve this is by building data-warehouses…All managers love them: performance indicators, clients or production statistics (gorgeous figures should not lead to too significant action). This represents great opportunity for an ambitious IT wanna-be-manager: convince a big business boss he needs figures & indicators (to make him/her shine of course) ; ask for a small budget to get started…and along the way, more needs will pile up, so that you’ll be able to ask for more resource…and before you know it, you are ahead of a big team, congratulations! Of course, once the original boss moves to another job, the data-warehouse stays…and even if no one looks at its reports, who will have the courage to cut it?
Among the necessary soft skills: learn to never report bad news. You are paid to make your boss feel good, not to give people additional work! At the same time, someone needs to get the work done, make sure you don’t do too much so that you have time left, for instance to plan for your future carrier. There are some more soft skills you do need to master if you want to move up the ladder, remind me of them.
Some ideas to progress in the ladder: do not belittle! What is the use to simplify the IS of your firm? You will end up with less staff and less issues! Think long term: propose to add layers of IT so that you add sexy (sexy not useful) functionality…and more staff (yes, you can be a big boss too), so that later you might have more production problems (yes, you are important) requiring additional expert staff and raising architecture questions (yes you are an expert). We all have numerous stories about making boss the one who created the mess…
One of the best ways to achieve this is by building data-warehouses…All managers love them: performance indicators, clients or production statistics (gorgeous figures should not lead to too significant action). This represents great opportunity for an ambitious IT wanna-be-manager: convince a big business boss he needs figures & indicators (to make him/her shine of course) ; ask for a small budget to get started…and along the way, more needs will pile up, so that you’ll be able to ask for more resource…and before you know it, you are ahead of a big team, congratulations! Of course, once the original boss moves to another job, the data-warehouse stays…and even if no one looks at its reports, who will have the courage to cut it?
Wednesday, February 25, 2009
Project management - the Specifications Myth
A lot of delays in projects are seen as due to lack of specifications or change in specifications. Is it really the case, the root cause for delay?
In real life, we rarely or nearly never know in advance what will happen when we plan something. What we are looking for is an objective and we adapt to reality. Take the holiday planning as an example. You plan to spend some good time at some place, and when you are there, you go and discover and adapt your plans. You did not specify in advance all places, meals, wake-up time.... You concentrated on what was important to you, for this particular holiday. Why do we imagine specifications should be different?
I believe what is crucial to a project, even more an IT project, is to determine the objective in a clear simple document. A simple and separate document from the specifications. A document translating needs in objectives, in key drivers...and ideally in performance indicators! Something to look at from time to time as the project moves on and the environment moves.
Specifications are more the root cause to fights between IT and users than the route to success for the project. A simple document stating the stakes and the objectives goes a much longer way to get everyone on board and create condition for project success.
In real life, we rarely or nearly never know in advance what will happen when we plan something. What we are looking for is an objective and we adapt to reality. Take the holiday planning as an example. You plan to spend some good time at some place, and when you are there, you go and discover and adapt your plans. You did not specify in advance all places, meals, wake-up time.... You concentrated on what was important to you, for this particular holiday. Why do we imagine specifications should be different?
I believe what is crucial to a project, even more an IT project, is to determine the objective in a clear simple document. A simple and separate document from the specifications. A document translating needs in objectives, in key drivers...and ideally in performance indicators! Something to look at from time to time as the project moves on and the environment moves.
Specifications are more the root cause to fights between IT and users than the route to success for the project. A simple document stating the stakes and the objectives goes a much longer way to get everyone on board and create condition for project success.
Monday, February 23, 2009
Budget wisdom 1
This post is the first chapter of a lot more to come regarding budget processes for IT. This is a domain where although many efforts are made... process is often a painful and sub-optimal exercice.
My first comment will be on the frequency of the process itself: IT budget takes place once a year, and can take days and weeks (who says months?) of painful negotiation between business line managers, CIO(s) and CFO(s).
The end result is generally a one page synthesis presented together with a list of projects with budget asked for the coming year, envelops for applications maintenance & baseline (which can be infrastructure, management cost and more generic stuff). Most time is spent on discussing the budget for projects whereas it generally represents less than 30% of the overall budget.
Budget for IT should take place much more frequently than yearly. Business moves faster than the year - especially those days, and IT systems taking generally more time to adapt than business, it is necessary to revize its budget and resource allocation more frequently than once a year. A real time allocation of resource and budget to the best initiatives, to the best projects / application evolution budget envelops is an ideal... difficult to achieve. Still, a good governance with frequent re-prioritization of budget allocation brings a lot of value to the organization. So at the higher level of the organization, a quarterly revision of budget allocation is good practice.
The yearly exercice then becomes a natural global discussion where IT investments can be compared with other departments investments.
My first comment will be on the frequency of the process itself: IT budget takes place once a year, and can take days and weeks (who says months?) of painful negotiation between business line managers, CIO(s) and CFO(s).
The end result is generally a one page synthesis presented together with a list of projects with budget asked for the coming year, envelops for applications maintenance & baseline (which can be infrastructure, management cost and more generic stuff). Most time is spent on discussing the budget for projects whereas it generally represents less than 30% of the overall budget.
Budget for IT should take place much more frequently than yearly. Business moves faster than the year - especially those days, and IT systems taking generally more time to adapt than business, it is necessary to revize its budget and resource allocation more frequently than once a year. A real time allocation of resource and budget to the best initiatives, to the best projects / application evolution budget envelops is an ideal... difficult to achieve. Still, a good governance with frequent re-prioritization of budget allocation brings a lot of value to the organization. So at the higher level of the organization, a quarterly revision of budget allocation is good practice.
The yearly exercice then becomes a natural global discussion where IT investments can be compared with other departments investments.
Software development methodology and project management are waste of money (2/2)
Having said in the previous post that methodology is a waste of effort and money....because building software means capitalizing business knowledge... i would like to contradict my own text by adding that project methodology is about capitalizing project management experience, and therefore should reflect the knowledge of the organization regarding the way projects take place, and how to make projects successfull.
So, the subject is knowledge again.... and just like when the organization wants to learn about past projects (a process generally called project post-mortem), it is particularly usefull not to write but to read and learn (as opposed to what happens most of the time, which is precisely to write methodology and post-mortems and not to learn from them)!
Project methodology is about accumulating knowledge.
So, the subject is knowledge again.... and just like when the organization wants to learn about past projects (a process generally called project post-mortem), it is particularly usefull not to write but to read and learn (as opposed to what happens most of the time, which is precisely to write methodology and post-mortems and not to learn from them)!
Project methodology is about accumulating knowledge.
Wednesday, February 18, 2009
What issues do we address in this blog?
This blog is looking at some common sense practices in IT management in large corporations. It is trying to kill some birds regarding IS management, IT governance, project management and IT budget practices.
It might be provocative in order to shake up bad habits all large corporations might tend to. It might sound simple and yes it is...but we try to keep it not simplistic!
Please ask for more! Email us at IS7sins@gmail.com
It might be provocative in order to shake up bad habits all large corporations might tend to. It might sound simple and yes it is...but we try to keep it not simplistic!
Please ask for more! Email us at IS7sins@gmail.com
Tuesday, February 17, 2009
Software development methodology and project management are waste of money (1/2)
Project management methodology and Software engineering literature and articles flourish and flocks of consultants live from those! Still, overall, projects are late, and software quality remains poor. Do we believe CMMI and PMMI will help improving delivery or quality or are they just a waste of money?
My belief is that software development is about knowledge and in particular about business process knowledge acquisition: a software is the capitalized knowledge on a business process. Software embeds an intimate expertise of the concerned business process with the value proposition to make it more efficient: if you do not believe this, look at most software firms marketing material.
The way software is built reflects this knowledge accumulation. In big corporations, software remains in place for many decades and become so difficult to replace since the whole organization is organized to fit the software (or is it the other way around originally?).
Human beings do not fit traditional methodology and the lifecycle model. Specifications are a snapshot at a given time and within a moving context but delivery happen much later than the original needs in a sometimes drastically different environment.
Also, in real life, a development team does not know its goals and communicate poorly (the bigger the poorer). They risk no penalties for doing things wrong.
With methodology and tools, people build bigger software, not better software.
My belief is that software development is about knowledge and in particular about business process knowledge acquisition: a software is the capitalized knowledge on a business process. Software embeds an intimate expertise of the concerned business process with the value proposition to make it more efficient: if you do not believe this, look at most software firms marketing material.
The way software is built reflects this knowledge accumulation. In big corporations, software remains in place for many decades and become so difficult to replace since the whole organization is organized to fit the software (or is it the other way around originally?).
Human beings do not fit traditional methodology and the lifecycle model. Specifications are a snapshot at a given time and within a moving context but delivery happen much later than the original needs in a sometimes drastically different environment.
Also, in real life, a development team does not know its goals and communicate poorly (the bigger the poorer). They risk no penalties for doing things wrong.
With methodology and tools, people build bigger software, not better software.
Subscribe to:
Comments (Atom)
Posts
