January 21, 2009 at 2:25 pm
Comments posted to this topic are about the item Risk and Assumptions
January 21, 2009 at 8:17 pm
I would be working to lower risk as much as possible. Adopting techniques that you are confident in, learning new skills and then applying them, even in side projects, can help grow your skills, increase the chances of projects being completed that the client is happy with, and keeping you employed. Now is the time to reassess the way you work, and find ways to show that you can work with your clients to meet their needs in an efficient manner.
It's funny... I was just in a heated-debate thread about this very subject. One of my comments was that if you don't want to take the time to learn your own trade well enough to be good at it (ie, write good set based code as quickly as others can write a cursor), then get out of the business.
5 stars, Steve!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 22, 2009 at 2:26 am
Thanks and hopefully people will see that spending time learning and building skills is worth it.
January 22, 2009 at 5:29 am
I don't agree with this; "Efficient in their eyes, not yours"
This is probably one of the hardest things to do but; both you and the customer must think it's efficient. The customer will not always know what is efficient; which is why you have a job in the first place. You will not win the efficiency battle every time but the times you do will increase the confidence your management has in your team. Making you more valuable.
I do agree that not learning the skills will prove to risky in these times. Not knowing the skills will also make it harder to prove to management your way is more efficient than theirs.
January 22, 2009 at 6:04 am
"Risk comes from not knowing what you're doing." I think that's true and that's part of the reason we'd had issues in our financial markets over the last couple of years.
Steve, I could not DISAGREE with your premise more... Risk may come from not knowing what you are doing, but the biggest lesson coming from our financial mess is that these people knew exactly what they were doing - they were greedy, and ripping off honest citizens. For example, its very hard for me to imagine that Bernard Madoff did not know very well what he was doing as he unloaded his illegal scheme all over people. And it would be simply mindless to presume that the thousands of mortgage agents writing loans they knew the people could not pay - so they could get their commission - did not know exactly what they were doing.
So though I would respect Mr. Buffet, I would re-tinker the concept: Risk comes from people with low morals and no ethics who have bought into the concept that if they just take care of themselves, the rest of the world will somehow get by. It doesn't, it isn't and we can thank these jerks for our current state of affairs.
To that end, IT people should remember that they serve end-users, not themselves, and thus deliver something they can be proud of, not ashamed of. Pride in your work, and a knowledge that it is a reflection of you as a person, would go a very long way to keeping risk in check.
January 22, 2009 at 6:26 am
I do believe there were immoral people involved, people taking advantage of others. Those people exist, and unfortunately they are in plenty of businesses.
However, I have read quite a few things about risk analysis in banks and there were lots of people that built models designed to calculate risk, probabilities of default, etc., and they used this to lower capital requirements and increase leverage. Many people did this with the best of intentions, being more efficient in business, etc, and they should not have been allowed to do so. At least not without more extensive testing across years, perhaps decades.
They thought they were more closely calculating risk, but in fact they had flawed models that didn't take into account the changes at other companies (meaning a larger section of the financial community) and this actually increased their risk.
Or at least I think they are a big part of the problem. Not all of it, but a big part. People ripping off others, or making bad loans knowing they weren't going to hold them is another big part. Plenty of blame to go around.
I still think many people in software increase risk unnecessarily by not learning more about their craft and developing better, perhaps more difficult or harder to learn, techniques to get things done.
I agree that we have to work with clients, and help them understand, but many IT people forget that getting things done, getting what the client needs (not necessarily how they want it done, but the end result should matter) and build what they think works well, or works better instead.
January 22, 2009 at 6:31 am
I think the biggest issue is lack of true project management in IT. I know I struggle with taking all the information from users and accurately converting those to requirements and design. A lot of it is in knowing the right questions to ask.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
January 22, 2009 at 6:50 am
In my current environment, it seems that the folks I work with think that we should not have to know the business very well, which could lead to not knowing the right questions to ask. I came up through the business and landed in a pseudo-IT role, so I have the opposite perspective, where I can't understand how you can possibly deliver a valuable product when you don't know how it will be used.
I'm working to try and give the new analysts a basic understanding of the business based on my experience, hoping to improve the results of this cycle, but we shall see.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
January 22, 2009 at 6:52 am
I agree that it's always a good idea to learn new skills, apply them, and add more depth to your current skill set, no matter what state the economy is in. But, one important component to the risk of any project is the inability of IT managers and developers to effectively communicate with the business leaders and end users that they are supporting.
I've seen a good deal of bad programming and bad business analysis on software projects -often the final product doesn't support the needs of the business community, and a lot of work is required down stream to clean up the mess. Bugs can be fixed and efficiencies can be found when the problems are a matter of system performance. Adding to your skill set can cut down on these problems and allow you to code more efficiently and save many hours of development effort.
However, I feel that a lack of communication skills and direction for IT projects is even worse. If we don't have a true sense of what the business community wants to accomplish while using our software, we could write the most beautiful and efficient code in the world, and it will still be of absolutely no value.
January 22, 2009 at 7:24 am
However, I have read quite a few things about risk analysis in banks and there were lots of people that built models designed to calculate risk, probabilities of default, etc., and they used this to lower capital requirements and increase leverage.
One interesting thing I read (written by a quant) was that they built models that showed certain reasults. Then management came in and saw that the results didn't match their expectations, so they had the modelers tweak their models.
One of the biggest problems with the whole thing seems to be that the people making these huge financial decisions don't understand risk but thought they had the math down. See Fooled by Randomness, The Black Swan (both by Taleb), the Misbehavior of Markets (Mandelbrot), or one of the myriad of others talking about how the models just didn't match reality.
January 22, 2009 at 7:24 am
Ok - Risk. I like it. Risk comes from not knowing what you are doing.
So, how do you know what you are doing if you have never done it before? You have to take the risk and do it once in order to understand the full consequence of doing the project. Then the next time you repeat this project, there should in an ideal situation be no risk factor.
Risk is needed. Risk is good. Risk is fun.
The amount of risk that you take on needs to be determined. This is called calculated risk.
It is difficult to calculate risk properly. People generally have their own agendas and do not factor in risk properly. You don't always want a low-risk situation, and you don't always want a high-risk situation. You want to calculate how much risk that you can handle and go for it.
People who are contractors or own their own business live at a higher risk level than people who do the daily grind. This does not mean that when the market shrinks, they should be running around looking for that full-time permanent job. This may mean that they will have to dip into their savings for a bit and end up taking more vacation this year. If they don't have any savings, then they have been red-lining their risk and should have calculated their situation better.
They probably didn't know what they were doing, but next time the market dries up, they will have that safety net in place.
Mia
I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
-- David M. Ogilvy
January 22, 2009 at 8:26 am
My experience with software projects is that minimizing risk, or conversely, maximizing the possibility of success, is possible in the following ways.
1. Make sure, as an IT professional, that you have counterparts in the organization who have a vested interest and deep understanding of the business need. Of course, you must be able to communicate with them and understand as much as possible about the business, but they are the ones who will use and benefit from the project. They will also help to explain the project to other key players in the organization.
2. Strive to organize projects into incremental pieces. Whenever I been have involved in "big bang" projects that try to solve many problems with one large stroke, we have come in over budget and behind schedule. You must keep the big picture in mind so that the pieces you build will eventually all work together, but build it from the bottom up.
3. Get the best people you can. If you or someone involved in the project don't have the skills required, find a consultant who has been through the cycle before with the technology you are using.
4. Be flexible and willing to change course. This doesn't mean changing on a whim, but if you learn something today that would better the outcome of the project, then don't be afraid to bring it to the other key players for consideration.
Risk in itself is not good or bad, it's how we manage it that determines whether we move forward or back.
January 22, 2009 at 8:33 am
In my experience, most of the inefficiencies in technology projects take place during the requirements gathering phase. DBAs aren't typically involved in that stage, but for those of us in smaller, jack-of-all-trade shops, we need some basic training in requirements gathering. For example:
1. Eliminate the middleman and deal with the end users (frequently easier said than done).
2. Don't involve end users in usability issues. They'll have strong opinions, but they're not experts, and so you'll never get out of that infinite loop. Develop an expertise in usability and apply tried and true principles (requested feedback should be limited to "lipstick on a pig" issues such as colors, logos, ...).
3. Limit your questions to end users to the information needed for the end result--for example, either information to be contained in a report or the information to be displayed on a website. Again, don't discuss layout, and other usability issues. What information do they need?
4. Limit the database design to tables/fields holding data needed for the information defined in #3 above.
5. Do not involve end users in the design of input forms. Again, they're not usability experts. The design of input forms are a function of usability principles and the data defined in #4 above.
January 22, 2009 at 8:35 am
I promise that I didn't see dld's post before writing mine. Great minds and all that...
January 22, 2009 at 8:42 am
Chris (1/22/2009)
2. Don't involve end users in usability issues. They'll have strong opinions, but they're not experts, and so you'll never get out of that infinite loop. Develop an expertise in usability and apply tried and true principles (requested feedback should be limited to "lipstick on a pig" issues such as colors, logos, ...).
Yeah Chris, don't involve end users in useability issues. They are only the people that are going to end up using the product every day after it is shipped out. They shouldn't have anything to say about the useability of it. Nice one. Then when they come back and say that the UI sucks and it makes no business sense to them, you can charge them again to change it to what they want.
Chris, you are a smart and savvy business man. 😉
Mia
I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
-- David M. Ogilvy
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply