Management and Leadership

 A person has responsibility for a task if:  He is given sufficient authority to perform it  He is accountable for its completion  A person has authority to perform a task only if he is has adequate control over the resources necessary to complete the task.  A person is accountable for a task if failure to adequately perform that task carries professional consequences.

 Delegation is assigning responsibility of a task to a team member.  When delegating a task, the project manager must ensure that the team member has the authority to perform it and is accountable for the results.

 When the project manager creates a document, holds a meeting of interest to others, or makes an important project decision, all of the information produced should be shared and used with everyone involved in the project.

 All work products should be public  All team members, senior managers and stakeholders should have access to every work product produced for the project.  Project managers and team members benefit because they make more informed decisions.  Senior managers and stakeholders are always kept informed.

 Decisions should be made based on known guidelines  Published standards documents help others understand the way certain roles must be filled.  Documents should be based on templates when possible.  Process documents ensure that each project is done using a repeatable process.  Use performance plans to set expectations for individual team members.

 Prevent senior managers from seeing software projects as a cost burden  A project is successful if its costs are justified by its benefits.  Establishing a track record of successful projects is the most effective way for a project manager to reverse dangerous attitudes in senior management.

 Show senior managers the impact of their decisions  Decisions are frequently made based on gut feelings instead of objective analysis.  The people making decisions about the project need to understand the details.  Show senior managers that improving project management practices will help them meet their goals.

 Don’t confuse flexibility with always saying yes  Don’t agree to an unrealistic schedule.  Change your approach when necessary.  Don’t confuse “easy to describe” with “easy to implement.”

 Avoid common management pitfalls  Don’t manage from your gut.  Don’t second-guess estimates. ▪ Remember Brooks’ Law: “Adding manpower to a late software project makes it later.”  Don’t expect consensus all of the time. ▪ Sometimes, you need to 勉強 (a better term is 說服 ) your team when you know it is necessary but your team members do not believe it.  Make your mistakes public.  Accept criticism. (not easy for many people)

 Avoid micromanagement  Don’t expect to review everything  Don’t fall into the “hands-on manager” trap  Use transparency to your advantage  Don’t be afraid to let your team members make mistakes

 Q: if your team is falling behind, what will you do?  Answer1: ask them for their status. This will encourage them to give you excuses.  Answer2: gather the status yourself using the material that have made public and ask them about the specific problems.

 Address performance problems early  Work with each team member to develop a performance plan.  Set standards that are fair and attainable.  Measure each team member’s progress against known and agreed-upon goals.  Correct performance problems as early as possible.

 “Variety is the spice of life”  Did you see a software team with members that are  always stressed and full of fear to fail or completely indifferent to end results?  totally agree with each other and satisfied with their product, but very far from harsh reality?  competing and fighting for the true solution, but cannot achieve common goals?  always inventing something interesting, but cannot focus on work and deliver software?  overly disciplined, planning everything, but deliver mediocre boring results without any spark of imagination?  having excellent communication, rapport and environment, but spend most of the time talking than working?  sitting in separate cubicles without talking, barely understanding what others are doing?  Software Creation Mystery » Five Big Personality Traits of a Programmer_ Do They Matter.mht Software Creation Mystery » Five Big Personality Traits of a Programmer_ Do They Matter.mht

 Personality is hard to change’  You can make a performance improvement plan for problematic team member.  If you find a member has some problems, it is likely to have the problems for almost always until something hit him hard.

 What kind of good altitude you expect?  Take difficult goal or subjective as a challenge  不太在意未來的回報  不任性於自己的喜好 – 人生很難永遠做你有興 趣或喜歡的事情。通常能勉強你自己去做好有 意義但是不見得有興趣的事情, 就是成長的開始  樂於助人  給 10 分做 12 分 ( 不滿足於做完, 而是要做好 )

 The type of people in previous slide are hard to find.  The ugly truth  People works for money and make a living !! ▪ You must give future in their career. ▪ Career includes possibility for promotion, higher income and so on.  Sometimes, people do work for loyalty ▪ Because they feel comfortable under you and you are reasonable so they won’t switch job for a little higher salary ▪ They feel you will protect them and promote them. ▪ You give a vision for them.