Development
This presentation is the property of its rightful owner.
Sponsored Links
1 / 65

Presented by : Soudabeh Gorjinezhad Instructor : Prof. Mustafa İlkan April 2013 PowerPoint PPT Presentation


  • 61 Views
  • Uploaded on
  • Presentation posted in: General

Development. Presented by : Soudabeh Gorjinezhad Instructor : Prof. Mustafa İlkan April 2013. OUTLINE. Overreliance on One Person Departure of a Key Person Development Performed Ad Hoc Without Adequate Design Lack of Emphasis on Testing Inadequate Tools

Download Presentation

Presented by : Soudabeh Gorjinezhad Instructor : Prof. Mustafa İlkan April 2013

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Presented by soudabeh gorjinezhad instructor prof mustafa lkan april 2013

Development

Presented by :

SoudabehGorjinezhad

Instructor : Prof. Mustafa İlkan

April 2013


Outline

OUTLINE

  • Overreliance on One Person

  • Departure of a Key Person

  • Development Performed Ad Hoc Without Adequate Design

  • Lack of Emphasis on Testing

  • Inadequate Tools

  • Developers Who Do Not Share Knowledge

  • Lack of In-depth Review of Work

  • Users Who Regularly Contact Programmers Directly

  • Lack of Teamwork Among Developers

  • Developers Who Cannot Agree on the Details of the Technical Approach

  • Few Guidelines For Doing the Work

  • Lack of Applying Past Knowledge and Experience

  • Developers Who Are Concentrating on the Easy Parts First

  • Conclusions


Presented by soudabeh gorjinezhad instructor prof mustafa lkan april 2013

INTRODUCTION

System development has been an area of great interest for IT researchers andmanagers for decades. It is part of the core and roots of IT. Various methodologiesand software tools have come and gone. There was structured programmingand design now gone.

Why IT people are interest in system development ?

Why have so many techniques emergedand vanished?

The answer to the first question is: Importance andIssues. The same is true for the second question.


Overreliance on one person

OVERRELIANCE ON ONE PERSON

Discussion

This is not uncommon across IT. The IT group is small spread . The IT group cannot afford to have multiple people understanding the same things . it is the same

In an automobile, dealership some mechanics are trained to dealwith one specific car model or engine.

In networks, there may be a single highlytechnical troubleshooter.

In applications software, there may be only one programmerwho supports an old system .


Overreliance on one person1

OVERRELIANCE ON ONE PERSON

Impact

The impact can start with uneven workloads.

If nothing is going on with aparticular application, the specialized person may handle lower-priority work.Next door, in other cubicles, other members of the IT staff are working extra to get the work done .

There is the fear that if you put this specialized person to work on somethingelse, he or she will not be able to respond to a production problem. So the ITmanager leaves the person alone.


Overreliance on one person2

Overreliance on One Person

Detection

Looking at the allocation of people to jobs and applications, you can detect a problem. You can also view the workload. If the work is falling unevenly on the employees, thenthis is another sign of the problem.


Overreliance on one person3

OVERRELIANCE ON ONE PERSON

Actions and Prevention

If IT people want to prevent the problem in the system it will bethere because of the limited resources, range of work to be done, and timepressure. some actions:

In the extreme cases, you might consider buying an application to replace that which the programmer is supporting.

Another technique is to begin to have the person sharing knowledge.

Could the programmer document everything?

In our experience, this does notwork. For programmer, it took nine months of pushing the informationout. In many situations,the person sees the knowledge as security and power and will not want toshare it.


Departure of a key person

DEPARTURE OF A KEY PERSON

Discussion

Suppose that there is a tightproject deadline, and the critical person, user or programmer, bails out.

Who is a key person? It is not just someone with special knowledge or skills.It can be someone on whom you have learned to rely because of past performance.


Departure of a key person1

DEPARTURE OF A KEY PERSON

Impact

The work that the person was supposed to do is now undone. The schedule suffers. It will take time and a learning curve for someone new to catch on and catch up. The management may feel that the work is not well managed. This is particularly true among userswho are told that their system will not be delivered on time because of the lossof a key person.


Departure of a key person2

DEPARTURE OF A KEY PERSON

Detection

There are signs that a person may be intending to leave.

The individual maybe absent from work to go on interviews. Earlier, he or she may be showingless interest in the work, becoming more detached. The person may not wantto share information as much as previously. You can sometimes detect the problem by what coworkers tell you.


Departure of a key person3

DEPARTURE OF A KEY PERSON

Actions and Prevention

You can take steps to mitigate the damage.

One is that any critical personshould not be given tasks that do not deliver milestones or results for weeks ora month or more. If the person leaves before this is done, there could be a majorloss.

Another step is to implement joint tasks. That is, two people are assignedto critical tasks, with one in charge.

Whatbenefit does this give the IT manager? If two people work together, you aremore likely to get the status of the work.

You will also find out more aboutattitudes of the staff members.

Another benefit is that you will have some degreeof backup.


Development performed ad hoc without adequate design

DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE DESIGN

Discussion

Improved development environments are now available. The tools themselvesare improved. Design is simpler since we are often dealing with componentsand object libraries.

Today, we have to specify how components and modules will relate. While thegoal of efficiency is somewhat replaced with effectiveness, creating effectivesystems means designing for flexibility and maintainability.


Development performed ad hoc without adequate design1

DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE DESIGN

Impact

If you rush pellmell into development, experience reveals that programmingsometimes has to be redone several times. You find things during the programmingthat cause you to rethink the development.The more you redo something and make changes, the more complex theprograms become. Then they are more difficult to change and enhance later.This can play havoc with the schedule.


Development performed ad hoc without adequate design2

DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE DESIGN

Detection

How much effort is going into design? Now, it is possible to begin programming some parts of a system if the design is not yet completed. However, with too much of this, you will see the issue arising.


Development performed ad hoc without adequate

DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE

Action and Prevention

Design is not what it was years ago. You do not have to spend as much timedesigning the detailed user interface, since most of these are Web based. A good idea is to plan out the work to answer the following question: Whatis the minimum amount of design work necessary? To address this questionyou must give attention to the areas that have the greatest risk.

A major fault of designwork in the past has been to focus on routine and easier parts of the design,with the hard parts left to the programmers.


Lack of emphasis on testing

LACK OF EMPHASIS ON TESTING

Discussion

A separate test environment supports a more structured approach to development and helps to support better configuration management practices.

Why don’t people, and in particular management, pay more attention to testing? One reason is the schedule.


Lack of emphasis on testing1

LACK OF EMPHASIS ON TESTING

Impact

For example: a person using his father’s credit card. He was trying different things withdiscounts. He found a way to combine three discounts to get merchandisefree. He did it and ordered $1,000 worth of goods.There wasno charge. Then he ordered $18,000 worth of merchandise. The same thinghappened. In a chat room he then posted how to do it. Within a week the firmhad received and shipped over $1.5 million in goods. They thought e-businesswas great until they found that they had given the goods away. For oneJapanese computer maker this was a problem. They advertised a new notebookon their Website. Almost immediately, they received many orders. This madethem curious Then theyread their own Website description, maybe some for the first time. Too bad,there were a number of zeros left out of the price in yen. In essence they gaveaway thousands of machines.


Lack of emphasis on testing2

LACK OF EMPHASIS ON TESTING

Detection

Rather than look at the testing, consider management’s attitude. Is there a separate testing group? Or is the only testing performed by developers? How are the testers trained, paid, and incentivized? Is there a separate test environment? Answers here can be very revealing. You can also probe the actual testing, but this is often enough for you.


Lack of emphasis on testing3

LACK OF EMPHASIS ON TESTING

Action and prevention

There should beseparate testers organized apart from the developers, for separation. Here isanother tip from our experience: Use the children of employees to do testing ofWeb-based software. Give them small gifts for each problem they uncover.Assign the older kids to review the text of the Web pages, with similar incentives.Kids, we have learned, have infinite time and are Sometimes more inventivein finding ways to break the system than adults.


Inadequate tools

INADEQUATE TOOLS

Discussion

Each technical IT function has its own tools. Here is a sample list. Thesetools may be provided by the manufacturer of the hardware, network hardware,or software.

Thethird-party products were originally created to fill holes in tools made availableby the manufacturers. Over time, if the third-party software is successful, thenthe manufacturer may buy the third party or develop and sell their own competingproduct. So the mix of available tools changes over time due to this factorand new releases of current tools.


Inadequate tools1

INADEQUATE TOOLS

Editors Debuggers Testers Compilers Network monitoring Network management Capacity planning Design documentation Program design aids

How can this be today? Aren’t there enough?

You can never have sufficient toolsif you are a programmer Things are better but by no means perfect.

In what wayscan the tools be inadequate?

Several tools might work well individually, butthey do not interfacewith each other well .There are guidelines or best practices on how best to work with the tool . Every tool supports a method. It is possible that two different toolssupport different methods. People are forced to use the two toolsbecause they provide value and there is nothing else on the market.


Inadequate tools2

INADEQUATE TOOLS

Impact

As you know from working around a house, apartment, or car, if you have poor tools, it will take longer to do the work. Inadequacy can lead toadditional, unplanned work. It takes as much or more time to learn how to use the tool effectively as itdoes to do the work.Another impact lies in frequency of use.


Inadequate tools3

INADEQUATE TOOLS

Detection

You should catalog the current state of methods and tools for both internalIT staff and the consultants and IT vendors. The tool supports a method and makes it easier to follow . This, combinedwith improved productivity, provides the management benefit for the methodand the tool.What happens if you have an area with either no method or tool or both? TheIT staff and/or consultants improvise their approach. There is inconsistency.There are three additional elements in the table. Whether guidelines exist inbest practices should be indicated. If no guidelines are available, then theremight be a problem.Without an expert, the IT staff who work with the method and tool can flailaround trying different approaches. This can waste time.The last element is management expectations. Since the other elements ofthe table are technical, you might wonder why this is here. That’s because theIT staff and consultants should know what is expected of them. They can thenattempt to get the best use out of the methods and tools.


Inadequate tools4

INADEQUATE TOOLS

Actions and Prevention

That can reveal where the gaps are. Wherethere is a gap, people tend to invent their own individual solutions. Try toprevent this or act on the problem by filling the gap. Experience shows that youcannot address all of these, since you are not in the tool business.Next, you might reconsider the choice of tools. Maybe another method hasa wider range of aids and tools. The other method is more widely used.


Developers who do not share knowledge

DEVELOPERS WHO DO NOT SHARE KNOWLEDGE

Discussion

Developers or engineers may have taken years to acquiretheir knowledge and experince . Software developershave created their own modules that perform certain functions.We did this as programmers starting with assembler andthen COBOL, C, FORTRAN, Visual Basic, etc. These modules are products ofyour knowledge and creativity. They help you to be more productive and cangive you a competitive advantage.It is not surprising to us that technicalstaff are now willing to share knowledge. If you share how you do things, others could do the same work.The experience and knowledge gives an edge to senior people in many fields.That is a main justification for paying them more than junior people with thesame amount of formal training. That is the same situation for teachers inseminars and classes. A senior person, such as a full professor, has more knowledgeand experience than a junior one. Both can teach out of the same textbooks,but the senior professor adds value through experience and knowledge.


Developers who do not share knowledge1

DEVELOPERS WHO DO NOT SHARE KNOWLEDGE

Impact

If management does not value experience and knowledge, then they cannotsee the value of this in the work. They see one person as interchangeable withanother. This can drive the senior people to seek positionswith firms that do value the expertise, knowledge, and experience.While it is understandable and mostly acceptable that complete knowledgesharing is not possible or even desirable, there are many times when somesharing of information is needed in IT. Developers need to share informationwith the people who will do maintenance. If the developers do not share theknowledge, they end up supporting the software and systems in production.Why would people want to do this? Ifthey do maintenance, then they have a long-term job.


Developers who do not share knowledge2

DEVELOPERS WHO DO NOT SHARE KNOWLEDGE

Detection

Take a look at the individuals who are providing maintenance, productionsupport, and enhancements. If they are the same ones who did the development,you have observed the issue. Another sign appears if there is a big diffrencein the skill and knowledge levels between junior and senior IT staff. This indicatesthat the senior people are hoarding information. After all, knowledge ispower in this case, informal power.


Developers who do not share knowledge3

DEVELOPERS WHO DO NOT SHARE KNOWLEDGE

Actions and Prevention

You cannot force people to share knowledge directly. the senior person may share only a part of theinformation What can you do indirectly?

First, you can implement the approach of sharedtasks. This can provide pressure to getthe individual to open up to someone else.

A second step is to implement lessons learned meetings.Since they are not being singled out, they are under major political pressureto participate. It will eventually be their turn.A third technique is to reward knowledge sharing. This is rare.


Lack of in depth review of work

LACK OF IN-DEPTH REVIEW OF WORK

Discussion

The most asset in IT groups is not money it is time. There istoo much to do and too little time. The pressure of time carries across all ITwork. An IT leader may think that since the IT staff members are qualified, it isunnecessary to review their work in detail or depth. If the leader tries to dothis, the individual may take offense, responding, “Don’t you trust me? I saidit was done.” The IT leader may not be technical or have a technical backgroundand thus may be intimidated by a technical review, fearing a loss of respect andesteem if any ignorance is revealed in the review.


Lack of in depth review of work1

LACK OF IN-DEPTH REVIEW OF WORK

Impact

If IT staff members see that there is no in-depth review of their work, theymay be led to the false idea that management does not care about quality justget something done. The problems with quality then appear later. And, if youhave been in IT at all, you know a basic truth The later a quality problem surfaces,the more effort is needed to fix the problem . On the other hand, if you review too much, you take time away from otherpressing matters, such as resolving and addressing issues.


Lack of in depth review of work2

LACK OF IN-DEPTH REVIEW OF WORK

Detection

It is too time consuming to examine the work quality in detail. Turn yourattention to the review of the work. Take a project, any significant project, andfind the milestones associated with tasks that have risk and issues. What reviewswere done?Next, focus on the small projects and non project work. What problems and issues exist for this that are traceable toquality?

What surprises have appeared recently? Are these technical?

Can they be traced to quality.


Lack of in depth review of work3

LACK OF IN-DEPTH REVIEW OF WORK

Actions and Prevention

Let’s examine how building inspectors conduct reviews. They cannot review everything even in a small house. What do they do? Time is short. They concentrate on where they haveseen problems in the past, testing these areas first. If these are acceptable, thismay end the inspection. If not, then they probe in more depth. They may askthe contractor to explain how they did the work.That is an approach suitable to IT. First, you want to determine in the project. This is where you want to give moreattention.


Lack of in depth review of work4

LACK OF IN-DEPTH REVIEW OF WORK

Here are some questions to get answered. The answers canhelp you zoom in on specific areas of greatest risk and with the most and severestissues.

What problems did they encounter?

How did they address the problems?

What surprises did they experience?

What did they learn from the work?

What was the hardest work?

What do you do with the other work?

Do you just accept it as is?

No. Here youcan do what we have done with our children’s schoolwork. There is too muchhomework to review, so you focus on the classes and subjects in which they arethe weakest. This is the test of existence.For work in between existence and a detailed review, This can be a starting point for a detailed review as well.


Lack of teamwork among developers

LACK OF TEAMWORK AMONG DEVELOPERS

Impact

The effect of a lack of teamwork is that IT people work alonefor the most part. Management sees no value in teamwork; some of the IT staffdon’t either. If people areall working in single cubicles separated by high partitions (à la Dilbert), thenthis tends to discourage teamwork. There is no place to get together except ina conference room. But conference rooms have to be reserved and are formeetings.If there is no or little teamwork, the issue of lack of knowledge sharing willappear. Without teamwork,IT management has no backup for a person. This slowsdown the work while a replacement is found. When someone else arrives to dothe work, the person has no one to teach them the essential information quickly.


Lack of teamwork among developers1

LACK OF TEAMWORK AMONG DEVELOPERS

Actions and Prevention

Here are the actions we often take.

Assign shared tasks, with one person in charge. This will ensureaccountability. Change the physical layout of IT. Implement shared offices to encourageteamwork and knowledge sharing.

Implement lessons learned meeting to facilitate teamwork. Reward teamwork as well as individual work.


Lack of teamwork among developers2

LACK OF TEAMWORK AMONG DEVELOPERS

Detection

Look at the layout of the IT space. Does it facilitate teamwork? Next,examine the project plans. Are most or all of the tasks assigned to only oneperson? If so, you have the issue. Another thing to observe is the content ofmeetings. If the meetings deal with administrative matters, then there is littleor no teamwork.


Users who regularly contact programmers directly

USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY

Discussion

When IT gets a maintenance request, it is often handed off to theprogrammer directly. There is no perceived need in doing project management.It is too small. Also, the level of risk is not thought to be high.This work puts the programmer directly in contact with the users. The userslike this because they are not talking to some IT manager or middleman. Theprogrammer has no middleman and can get and give information quickly.At first glance this seems to be a maintenance and operations issue.Many programmers are involved in development and maintenance at the sametime, so the issue can affect their work in development negatively.


Users who regularly contact programmers directly1

USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY

Impact

Experience reveals that once users are put in direct touch with the programmers,they easily calling them directly. Why bother puttingthrough a request for a “small” change? Just pick up that phone or tap out ane-mail and get help directly. It is better than a 911 emergency call. More often than not, the programmer is seatedat his or her desk. No call-waiting. The programmer is now interrupted andmust drop work to handle the call. After the call, it will take some time for theprogrammer to regain the concentration to continue working. This wastes timeand reduces productivity.Programmers often are people who like to please the users . Rodney Dangerfieldsaid, get a “little respect.” So the programmers tend to be very responsive tousers when put in direct contact. They will not ask critical or negative questionssuch as “If we are unable to do it, what will you do?The user has a seemingly innocent and simple request. Just change a screenor report or handle a new exception.


Users who regularly contact pogrammers directly

USERS WHO REGULARLY CONTACT POGRAMMERS DIRECTLY

Detection

Here are some questions to answer.

What are the programmers working on now?

How did they spend their time in the past two weeks?

What was the source of the work?

How much and what work came from users directly?

Once you uncover this, you can find out which users are goingdirectly to the programmers.


Users who regularly contact programmers directly2

USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY

Actions and Prevention

One approach is to go to the users and tell them they have to go throughchannels. Just like an automobile dealership, customers do notgoing directly to the mechanics. Here is ITmanagement again trying to put barriers in the way of getting the work done.

If this is not a good idea, what else can you do?

First, you should hold ashort meeting on a weekly basis among the IT supervisors and project leadersand allocate the programmers’ and others’ time for the coming week . Thenfollow up during the week.Another step is to talk to the programmers about the agendas and politicsof users . Users sometimes tend to exploit their relationship with individual ITstaff to show that they have informal power. They can get things done for thedepartment that their own management cannot get done. King and queen bees


Users who regularly contact programmers directly3

USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY

can be expert at this. You want the programmers to realize that they can bemanipulated.Next, appeal to their self-interest. If all the programmers did was respondto users, they would get little done. Their work would not be significant to thebusiness. Their value as employees would be diminished. They are insteadbeing used, abused, and manipulated.


Lack of teamwork among developers3

LACK OF TEAMWORK AMONG DEVELOPERS

Discussion

IT does many projects. Projects are things that are supposed to be done bya team. What do the words team and teamwork mean? They mean workingtogether . The problem arises in ITmanagement. IT managers associate teamwork with meetings. However, if themeetings are mainly status meetings, then there is no teamwork. Each persongives his or her status while others in the meeting go mentally asleep until it istheir turn to report.Why does this arise? Managers, especially ones with less experience or thosewho are insecure, want accountability. To them, accountability means the focusis on the individual and his or her performance . The managers may feel that teamworkwill slow the work down. While they may see long-term benefits to teamwork,they are intent on achieving short-term results.


Lack of teamwork among developers4

LACK OF TEAMWORK AMONG DEVELOPERS

Impact

The effect of a lack of teamwork is that IT people work alone in the most cases . Management sees no value in teamwork . The work layout and arrangement can reinforce this. If people areall working in single cubicles separated by high partitions (à la Dilbert), thenthis tends to discourage teamwork. There is no place to get together except ina conference room. But conference rooms have to be reserved and are formeetings.If there is no or little teamwork, the issue of lack of knowledge sharing willappear.

Without teamwork,IT management has no backup for a person if he or she departs. This slowsdown the work while a replacement is found. When someone else arrives to dothe work, the person has no one to teach them the essential information quickly.


Lack of teamwork among developers5

LACK OF TEAMWORK AMONG DEVELOPERS

Detection

Look at the layout of the IT space. Does it facilitate teamwork? Next,examine the project plans. Are most or all of the tasks assigned to only oneperson? If so, you have the issue. Another thing to observe is the content ofmeetings. If the meetings deal with administrative matters, then there is littleor no teamwork.


Lack of teamwork among developers6

LACK OF TEAMWORK AMONG DEVELOPERS

Actions and Prevention

We encounter this problem most of the time when we take over an IT groupto turn it around.

Here are the actions we often take.

Assign shared tasks, with one person in charge. This will ensureaccountability . Change the physical layout of IT. Implement shared offices to encourageteamwork and knowledge sharing.

Implement lessons learned meeting to facilitate teamwork . Reward teamwork as well as individual work.


Developers who cannot agree on the details of the technical approach

DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH

Discussion

This issue crops up in construction, auto repair, and other fields as well.Technical people come from different experiences and backgrounds. As such,they often have different views on a technical approach.This is actually a good thing an opportunity. It goes bad when the disagreementsare not controlled and continue unabated for days or weeks. Thenit is an issue.


Developers who cannot agree on the details of the technical approach1

DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH

Impact

One potential impact is that in the short term, work is delayed while peopletry to decide what to do. Often the IT managers do not get involved. Theproblem worsens. For technical staff, it can be very personal and nasty. Over the longer term, we have seen this issue grow to divide the IT staffmembers into warring camps. Each camp adheres to a specific philosophy. Itis difficult to get things done under these conditions.


Developers who cannot agree on the details of the technical approach2

DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH

Detection

Sometimes you can detect the issue by listening to what people say in free time. Then you can tell ifthe problem is growing when the discussion moves into project meetings.Another idea is to focus on a facet of the technical issue and see how stronglythe staff members react. This will indicate the depth of the disagreement.


Developers who cannot agree on the details of the technical approach3

DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OFTHE TECHNICAL APPROACH

Actions and Prevention

You have to look at the problem from a management perspective. After youdetermine the source question or issue of the disagreement, you can find the answer

What is the impact on the business and business processes of eachalternative

This can force the IT staff to talk in businessterms.


Developers who cannot agree on the details of the technical approach4

DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH

What is the impact in IT on current work?

What is the impact in IT on maintenanceenhancements, and support?

What if we continue to do what we are doing now?

Is there another option?

IT people sometimes have hidden agendas. They may feel that if they win onthe question, they will have easier work, more informal power and so on.


Few guidelines for doing the work

FEW GUIDELINES FOR DOING THE WORK

Discussion

This issue does not pertain to requirements; rather, it is about what is to bedeveloped. Underlying this issue is the fact that IT maybe doing this for thefirst time. In Star Trek terms, “You are going where no one has gone before.”

Isn’t most IT work related to some previous or existing work? Yes, of course.This is the exception.


Few guidelines for doing the work1

FEW GUIDELINES FOR DOING THE WORK

Impact

This can give the project leader very conservative estimates based onfear, not on reality and hard information. Another impact is the burden of getting the project and work falls on the shoulders of the IT leadership. If an inexperienced IT person is incharge of the work, there could be a time of paralysis. This is anotherdelay.


Few guidelines for doing the work2

FEW GUIDELINES FOR DOING THE WORK

Detection

When there is any new work, we have already said that you should examinehow it is similar to the past and present work. From experiencewe have learned even radically new technology, systems,and projects still bring many similar tasks.


Few guidelines for doing the work3

FEW GUIDELINES FOR DOING THE WORK

Actions and Prevention

What will it taketo become somewhat proficient about the new? lack of time to learn all of it . Make a list of what is important.Stick to As staff members are learning it, try to force the immediate application ofthe knowledge. Also, so that the project is not terribly slowed down, you shouldinitiate other, parallel work in data conversion and the like. Hold lessons learnedmeetings to share the information. The manager should attend these. Feel freeto ask questions.


Lack of applying past knowledge and experience

LACK OF APPLYING PAST KNOWLEDGE AND EXPERIENCE

Discussion

Some IT people have been trained to approach problems asnew. Yet history tells us that this was a vital factor in thesuccess of military campaigns.

Look at ancientRome. The technology and methods for building improved for manyyears until the Romans had, in their time, perfected it . There is evidence thatthey used lessons learned. It has been the same with famous militarycommanders, such as Alexander the Great, Hannibal, Napoleon, andmodern-day successful generals. Why doesn’t everyone in IT use lessons learned? One answer is culture.People may want to think that what they do is art.


Lack of applying past knowledge and experience1

LACK OF APPLYING PAST KNOWLEDGE AND EXPERIENCE

If it is art, then each project is unique. The work is unique. The issues and problems are unique. You mightbe able to reuse some knowledge of tools that will be reused again and again;but for management, analysis and so on.

the work is unique This attitude helps toprevent cumulative improvement. With this view a person tends to make thesame mistakes again and again like in the movie Groundhog Day. From the perspective of some IT managers, there is pressure to get the work done Just do it. Don’t sit around and relive the past. This tends to send a clearand unmistakable message to the staff that experience is not valued.


Lack of applying past knowledge and experience2

LACK OF APPLYING PAST KNOWLEDGE AND EXPERIENCE

Impact

The short-term impact is that you will probably just plunge in and proceedwith the work. At this situation you do not realizethat you are going through the same steps and problems as before. You couldhave done this in less time or avoided it all together had you appliedexperience.If you do not value the past, you will not make much of an attempt to gatherlessons learned from the past. If you just concentrate on the present, there willbe no cumulative improvement. You will never get any better at solving issues.


Lack of applying past knowledge and experience3

LACK OF APPLYING PAST KNOWLEDGE AND EXPERIENCE

Detection

Look at how people approach the work. Do they try to apply what theylearned? Now watch what happens when they finish a phase of work. Do theygather lessons learned? If not, you have the problem.


Lack of applying past knowledge and experience4

LACK OF APPLYING PAST KNOWLEDGE AND EXPERIENCE

Actions and Prevention

If there is no effort to apply the past knowledge, then at the start of work,people ask questions such as these:

What is the situation?

What is wanted?This does not sound too bad. Now look at it from the perspective of usingknowledge from past work. If you received a new piece of work and appliedyour experience, the questions would be more wide ranging and deeper:

How is the new situation like the old?

How can I apply past knowledge to get this done faster?

Whatwas it in the past?

How did wedeal with them then?

How would they be applied now?


Developers who are concentrating on the easy parts first

DEVELOPERS WHO ARE CONCENTRATING ON THE EASY PARTS FIRST

Discussion

For many of us this is a natural thing to do. If we get the easy parts completed,we show progress fast When our parents asked about our homework, we could truthfully say wehad half of it done. Our parents were happy. We were happy.

Too bad that thehard part was still to come. At home this blows up when you still did not finishand the clock on the wall says midnight.

Why? You left the hard parts of thehomework until the end.


Developers who are concentrating on the easy parts first1

DEVELOPERS WHO ARE CONCENTRATING ON THE EASY PARTS FIRST

Impact

Many IT managers did not do programming. When they ask the programmer about status,they get a percentage complete number that sounds good. They update theproject or work status accordingly. They are inherently assuming that the worktasks are all equal. In COBOL this was true because much of the code was inthe data definition section. So a programmer could truthfully state that a highpercentage of the lines of code was complete. But there was no risk here. Beyonda false sense of security, problems and issues about the rest of the work are notaddressed. They will likely be discovered later, but at a higher price.


Developers who are concentrating on the easy parts first2

DEVELOPERS WHO ARE CONCENTRATING ON THE EASY PARTS FIRST

Detection

Look back over the recent past and ask if there have been some unpleasantsurprises in which the programmer took longer than estimated or, alternatively,came across a problem toward the end of the work. These are good signs of theissue


Developers who are concentrating on the easy parts first3

DEVELOPERS WHO ARE CONCENTRATING ON THE EASY PARTS FIRST

Actions and Prevention

Identify ahead of time which areas of the work are riskier. These mightinclude testing, business rules, and interfaces. If, as an IT manager, you wantto ask the programmer about something, ask about these areas. This will accomplishtwo things.

First, it will give you more correct information.

Second, it willreveal to the programmer that you are on top of the areas of risk and issues.


Conclusion

Conclusion

If these issues have been around, then whydon’t they stay fixed after being addressed?

Why is there so often recurrencein this area?

Well, for one thing management has not changed much in IT. The emphasis is still on individual work versus teamwork. There is severe timepressure, so the key-person problem is there

Maybe, rather than keep changing the technicalapproach, more attention should be paid to the management problems in IT.


Thank you

Thank You

?


  • Login