Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Software Project Management

News See Also Recommended Books Recommended Links Selected Papers Usenet groups Reference
Project micromanagement Toxic managers  Overload Stress Tips Humor Etc

.Although documentation is very important software projects rarely fail due to lack of "progress reports". The main reasons are unrealistic goals, incompetent managers as well as lack of communication and collaboration. One o the main dangers is Project micromanagemen

Micromanagement as a business term has one of the most negative connotations: "He's a micro manager." is essentially the same as, "He is driving me crazy." 

Notes:
  • Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books.
  • The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Search Amazon by keywords:

Google   
Open directory

Research Index

 

Old News

Micromanagement  at smbresource.com:

 

How to survive a bad manager - scottberkun.com

The best advice for having a bad manager is to seek other employment. Don’t undervalue your happiness: it’s impossible to be happy if you work directly for someone you can’t stand. It may be difficult to find another job, but if you are willing to make compromises in other areas (salary, position, project, location, etc.) it will certainly be possible. Being happy and underpaid is a much better way to spend a life than unhappy and anything else.

Making life changes, even progressive beneficial ones, is difficult and leaving a bad manager might require weeks or months of less than pleasant living. However, on the other side of any decision to leave is something you can’t get where you currently are: the possibility of a good manager, and the sanity that it will bring you. The “never quit, tough it out” attitude is a mistake if you are in a situation that can never result in your satisfaction. I think the act of finding a new job, or even quitting before you've found one, can be a way to take more control. It puts you back at center of your life, where you belong. There are risks involved, but it puts you, and not your manager or company, at the center of them.

But for the sake of this essay I’ll assume that you are either unwilling or unable to leave. Maybe you’re looking for something new and have to endure a bad manager until you’ve found it, or perhaps your family is heavily dependent on you and your options are limited. That’s fine. Just remember to re-read the first paragraph every month or so to make sure you’re considering all your choices, and not hiding behind the deceptive safety of a merely acceptable job, when what you need is something more.

How bad is your manager?

There are many different factors that contribute to negative opinions of managers. It’s not the goal of this essay to list them all, but here are some of the basics:

Skimming this list should have one of two effects: Either you are now certain you have the worst manager in the history of civilization, or you’ve recognized a few bad traits that your manager does not have. If you are in the former group please re-read the first paragraph of this essay. Odds are good you can do better.

For most of you the above list should point out a few bad qualities your manager does not have. This is good. You should take a moment to imagine how much worse it could be (picture an evil manager, wearing a red cape, in a dark dungeon of a cubicle farm, laughing to himself as he uses the list above as a checklist for his daily activities). If you can see some behavior in your manager than isn’t as bad as others there is room for you to make better use of your manager.

[Feb 2, 2007] Tech makes working harder, not easier

Where is the Real Value ?

It can take me several hours just to set up Outlook to file the email that I really don't care about automatically...

Or to report my time, according to different criteria; to multiple time reporting systems (which generally are hideously unfriendly)... And make sure they all match regarding Totals and Projects. Too often sub-tasks are really meaningless burdensome breakdowns based on micro-management methodologys - or some bug infested Excel document that has partly-coded relationships and Totals...

Project micromanagement is often just in the way of figuring out what needs to be done and doing it.

Some of the Document templates that have been developed are an exercise in wasted time - heck I just had a small project to add a field to an extract file, had it coded and ready to implement...then the Project Lead asked me to generate a Specification Document using a 40+ page template - well that is taking longer than the work to do the change itself.

And I'm still envisioning the value added by requiring mixed-case alpha and numeric passwords changed frequently on platforms that have conflicting rules so that the passwords end up differing - a real technological plus would be to use a fingerprint instead (and don't ask me to change it weekly either)...

What's needed is vigilance about if we're working for the technology - or if it's working for us...

Software Project Management Micromanagement

Today, I’ll write something so obvious that I’m almost ashamed of it. I thought if there’s anybody who doesn’t know that, but I still see lots and lots of people who act like they should read below advices. There’s a second reason also – it’s always worth to remind to myself these points.

Micromanagement, that’s what I want to write about today. Why is it bad? There’s a bunch of reasons:

  • Manager can’t do everyone’s work. He has in the team 5, 10 or maybe 50 people, so in every case they do more than a single person could. Even if he’s a superhero. Even if there’s only one person in the team. Remember the manager has his own work. Oh, at last he should have some.
  • Manager’s competence doesn’t cover all competence in her team. She usually isn’t the best developer, the best tester, the best project manager. She has the best managerial attributes. Oh, at last she should have some. That’s why she’s the boss. I hope that’s the reason, in other case I offer my condolences to you.
  • Telling people how exactly they should do their tasks is usually stupid because they usually know better. They are closer to issues, closer to code/functionality/project plan/whatever and they work on that every single day (not only during micromanagement day of the week). Manager is like a driver – he can say if the car looks nice and drives fast. His team is like mechanics – they know what exactly happens in the engine. You’d rather ask the mechanic, not the driver how to fix brakes in you car, wouldn’t you?
  • In these several cases when the manager knows better what to do and how to do, telling people how exactly they should do their tasks is stupid, because people don’t learn accountability then. If the manager taught them micromanaging, they won’t take initiative, won’t be creative and won’t look for improvements of their work. Why should they? That’s the manager who tells them exactly how to work. But remember, she doesn’t have the time to micromanage every single person on regular basis. Even if she’s a superhero.
    Yeah, stupid indeed. It’s obvious. Why to write about that? I’ll answer with a question: why so there’s still so much micromanaging?

    I think reasons are different. When I recall micromanagers I met they’re driven by different demons. There’re two I Know It Better demons – first when the manager really know better how to deal with a task or an issue and second when he thinks he knows. The latter is much more common. There’s Do What I Say demon, when it doesn’t really matters if the solution is right or wrong, it’s all about doing what the manager said just to support his ego. There’s You Don’t Know The Big Picture demon, when micromanaging is justified with lack of wide knowledge about whole situation within the team. Nothing easier but to share the knowledge. There’re of course others, but those are the most common.

    You should listen none of them. There’s always a better way to deal with the task or the issue than micromanaging. You can come with your idea in every situation but don’t treat yourself as unmistakable, because you’re not (I bet). Bring discussion and be open to change your mind if someone, especially someone who’ll actually do the work, comes with another idea. And tell people what to do, not how to do that.

  • Politics-Oriented Software Development kuro5hin.org

    Introduction

    Most textbooks and methodology guides start with statistics proving that software projects are disastrously prone to failure. I'll take that for granted.

    They then propose complicated rules designed for a fantasy business world where cooperative workers idealistically work towards the common goal of maximizing shareholder value.

    A couple of weeks in a typical office should disabuse you of that. Real world companies are made up of individuals working for their own goals: career advancement, more money, or just the chance to slack off. Occasionally it may be in someone's interest to build a successful project. Usually it's more useful to sabotage it.

    This leads to the real reason for the perpetual software crisis:

    1. Most software fails because it is designed to fail

    Why you should want your project to succeed

    A developer rarely benefits from the failure of his project. There are exceptions, such improving your resumé by choosing bleeding-edge technology that may also cripple the project. However, few developers escape the consequences: they may be stuck maintaining an inadequate system long after the project manager has moved on to better things.

    In addition, since management is a less specialized skill, it is easier for a manager to change jobs than it is for a developer.

    Sabotage

    There are two kinds of sabotage: deliberate and incidental.

    The direct manager of a project has an incentive to see the project succeed. As we will see later, he may also have incentives to make the project fail, but generally he wants to get it working, at least in the short term until he gets promoted.

    In most companies, promotion is competitive. This means that the direct manager's competitors have an incentive to make him fail: deliberate sabotage. This tendency is most prevalent in non-software houses that have several teams of in-house developers. It obviously doesn't arise if there is only one software development manager, and in software houses the chance of expansion renders the competition less fierce.

    Because everyone has to pay lip service to the good of the company, deliberate sabotage has to be disguised as incidental sabotage. Nevertheless, be aware that it's a good idea to keep sensitive information, such as estimates and necessary purchases away from potential rivals. Beware of casual conversations with the enemy.

    [Nov 10, 2005] Project management with Trac By: Keith Fieldhouse

    If you've ever been a part of a large development project, you've no doubt become accustomed to having access to source control and bug tracking tools and design document repositories. But what if you're part of smaller project where you're responsible for setting up your own infrastructure? Trac, an open source project sponsored by Edgewall Software Services, provides a complete project infrastructure that's easy to install and maintain.

    Trac integrates a capable wiki engine with a number of project management features. In particular, Trac provides a Web-based interface to a Subversion source code repository, a job/bug ticketing system, and basic scheduling features. Each of these is integrated with the wiki engine. Trac can be readily adapted to nearly any project management style.

    For the purposes of this article, we'll assume that you use Subversion for your source control system. If you're not familiar with the software, you may want to review my recent article on using Subversion or take a look at the Subversion Book to get started. You will also need a Python 2.3 installation, the python bindings for your installation of Subversion, and an installation of PySQLite; use version 1.x or below, as the current stable version of Trac doesn't support PySQLite2.

    Users of Debian-based Linux distributions can install all of these prerequisites and Trac itself by simply executing apt-get install trac as root. Packages for Trac can be often be found in other repositories for distributions such as Fedora. There are Microsoft Windows binaries for Python, the Subversion python bindings, and PySQLite as well. If none of these options serve, the Trac Web site has information for installing Trac on a variety of platforms.

    The simplest deployment of Trac, which we'll outline here, involves using its own built-in Web server. For small to medium internal projects, this configuration should prove more than adequate. For larger or externally deployed projects, investigate Apache-based deployment options.

    There are two commands that are important in the Trac distribution: trac-admin and tracd. In most Linux distributions they'll be found in /usr/bin or /usr/local/bin. For Windows installs, these commands will generally be found in Python installation directory\Scripts.

    To create your Trac project you must choose a location in which Trac will keep its data. For our purposes we'll assume the directory /path/to/MyTracProject. (On Windows it could just as easily be C:\MyTracProject.) Trac must also know the location of your Subversion repository (we'll use /path/to/SubversionRepository). Given this information, use the initenv command to initialize the project:
    $ python trac-admin /path/to/MyTracProject initenv /path/to/SubversionRepository

    After initializing your Trac project you should able to run:
    $ python tracd --port 8080 /path/to/MyTracProject
    to start the built-in Trac server. Then, simply browse to http://localhost/MyTracProject:8080 to take a look at your initial Trac project.

    One thing that you'll notice is that the Trac wiki is pre-populated with pages that document the Trac system. For example, the wiki page at http://localhost:8080/MyTracProject/wiki/TracGuide is the table of contents for the Trac documentation.

    You can use the trac-admin script to configure other aspects of your project. Let's use it to add some project components and some scheduling milestones. While we're at it, we'll remove the sample milestones and components that Trac places in its database. The following commands will give you the flavor of working with the Trac administrative tool. There is also a help command that provides a summary of all of the available administration commands.

    $ python trac-admin /path/to/MyTracProject
    Delete default components
    Trac [/path/to/MyTracProject]> component delete component1
    Trac [/path/to/MyTracProject]> component delete component2
    Add a GUI and Database component
    Trac [/path/to/MyTracProject]> component add GUI
    Trac [/path/to/MyTracProject]> component add Database
    Delete the default milestones
    Trac [/path/to/MyTracProject]> milestone delete milestone1
    Repeat the above command for milestones 2,3, and 4
    Then add an Alpha, Beta and Release milestone
    Trac [/path/to/MyTracProject]> milestone add Alpha
    Trac [/path/to/MyTracProject]> milestone add Beta
    Trac [/path/to/MyTracProject]> milestone add Release
     

    Once you've set up the basic structure of your project you can begin to actually populate it. The toolbar at the top of the Trac Web pages lets you browse your project wiki, look at your project schedule (called the "Roadmap" in Trac), enter tickets (which can be bug reports or "todo" tasks or a combination), and browse through your Subversion repository.

    The real power of Trac is its ability to adapt itself virtually any project management style. Trac honors wiki formatting across the entire Trac-managed project. Naturally enough, Trac's wiki supports a full range of the usual wiki formatting behavior for links to other wiki pages, lists, emphasis, and so on. Trac, however, also supports special markup for creating links to milestones (milestone:Alpha), tickets (ticket:121), and source code (source:trunk/MyCode.cc). Thus, you can create wiki pages that organize access to any useful selection of project characteristics. Then, to extend the concept, Trac honors wiki formatting not only in wiki pages but in ticket descriptions and even Subversion check-in comments.

    With this ability to interlink various aspects of your project you can create a living view of your project's status. Consider a project being run using agile methodologies. Wiki pages can be used to describe user "stories" or use cases. These pages can be linked to "iterations" that are entered as the project milestones. Developer tasks can be entered as tickets associated with the appropriate iteration or milestone. As code is checked in to satisfy a particular developer task, the check-in comment can identify the task with a link to it. Thus, the project's state can be reviewed from virtually any perspective, where appropriate details are accessed with the click of a mouse.

    In addition to integrating well with itself, Trac provides a number of features that allow it to integrate well with the outside world. The URL scheme in Trac is constructed in a very sensible and predictable fashion. For example the URL in "MyTracProject" for the Alpha milestone pages would be http://trac.myco.com:8080/MyTracProject/milestone/Alpha. The URL for the seventeenth ticket is http://trac.myco.com:808/MyTracProject/ticket/17. Thus, it is quite easy to compose blog entries or emails that refer to aspects of a Trac-managed project. Trac also has the ability to create reports using SQL select statements against the ticket table in the Trac database, allowing you to provide customized reports for project stakeholders.

    All of this shows that any project, regardless of its size, can take advantage of Trac's powerful and sophisticated planning, monitoring, and reporting infrastructure. With a small investment of time, you can deploy and adapt Trac to your project management strategy, allowing you to concentrate on moving your project to completion and success.

    Recommended Links


    In case of broken links please try to use Google search. If you find the page please notify us about new location
    Google     

    Internal

    The Mythical Man-Month

    Rapid Development by Steve McConnell

    External

    Slashdot Book Excerpt The Art of Project Management

    How to detect bullshit - scottberkun.com

    How to survive a bad manager - What to do when you work for someone who doesn't know what they're doing.

    Software Project Management Resources -- Columbia University

     

    Software Project Management

    Free Software Project Management HOWTO

    Free Software Project Management Tutorial and Course and Guide

    Recommended Books

    See also Software Engineering

    The Art of Project Management Books by Scott Berkun

    Interesting book dispenses much needed advice, February 2, 2006
     
    Reviewer: calvinnme "Texan refugee" (Fredericksburg, Va) - See all my reviews
    Perhaps one of the reasons I am still doing engineering work rather than supervising it 26 years after I received my BSEE is that I could never properly wrap myself around exactly what it takes to manage a project. I therefore approached this book with a great deal of trepidation. However, after I began reading it I became pleasantly surprised. Most project management books I've read in the past intersperse advice on project management with software engineering techniques and Tony Robbins style motivational anecdotes.

    This one sticks to the subject and is well organized. The book is not about any one specific project management methodology, but about fundamental aspects of all projects. The author recounts his own experiences while managing projects at Microsoft to provide insight into the less transparent aspects of project management.

    The book is divided into three major sections: "Plans," "Skills," and "Management." This organization provides a logical flow overall and allows topics to build on one another. In spite of this logical progression, the chapters are fit for random access, as the author himself recommends. One of my favorite chapters was "Figuring Out What To Do". Here the author outlines three basic perspectives: The business perspective, the technology perspective and the customer perspective. The author states that although the customer perspective is the most important of all three that is the most neglected and is the reason that many projects fail.

    The chapter "How Not To Annoy People: Process, Email, and Meeting" was another chapter I really enjoyed. It offers down-to-earth recommendations on dealing with annoying behavior which the author lists in five categories:

    When others
    1. assume you're an idiot.
    2. don't trust you
    3. waste your time
    4. manage you without respect
    5. make you listen to or read stupid things

    Since I've been guilty of being on the giving end as well as the receiving end of some of this behavior, this chapter helped me see some of the trouble I can cause myself as well as how I can effectively deal with it when it comes from others.

    However, this book is more than just about how to deal with socially backwards misanthropes such as myself. It dedicates considerable space to creativity, dealing with ideas once you have them, making ideas actionable by using affinity diagrams to consolidate ideas, and employing iterative prototyping.

    The third section of the book, which is specifically about management issues, contains chapters such as "Why Leadership Is Based On Trust". In that chapter the author points out that trust is built through commitment but lost through inconsistent behavior. Leaders must develop enough trust that people will bring issues to them during crises instead of hiding them. Trust, then, is at the core of leadership. Part of the reason that people will not trust some leaders is dealt with in the chapter "Power and Politics." Specifically, the author points out that power is misused when people work towards their own self-interest. If that person is a leader, and other people take note of this misuse, trust is lost.

    In summary this book has much to say about all phases of project development as well as management. Highly recommended.
    "The beginning is the most important part of the work.", November 23, 2005
     
    Reviewer: Christopher Byrne "The Business Controls Caddy" (Atlanta, GA USA) - See all my reviews
    (REAL NAME)   
    "The beginning is the most important part of the work." So says Plato in The Republic. So perhaps it is fitting that The Art of Project Management (Scott Berkun, O'Reilly 2005, 396 Pages, ISBN 0596007868) is written by an experienced project manager that studied not only computer science and design, but philosophy as well. Clearly and thinking man, his thoughts and experiences as a product manager at Microsoft are tied into historical perspectives of grand projects of history, and translated into an easy to read and follow format. It does not matter if you are the sole developer on a project, part of a team, or the leader of a project. This book provides valuable wisdom and insight that the success of a project is dependent on strong project management and planning from the beginning to the bitter end.

    From The Pyramids To The Kitchen

    Berkun is keenly aware of and believes in the notion that project management is not a new concept. At the start of the book, he takes us back to the days when the great pyramids were built and to the present with thoughts about modern-day restaurant kitchens. The latter is highly organized chaos, much like flight operations on an aircraft carrier. In the busy kitchen, everything is run so smoothly and efficiently despite constant flux in the environment. It is the history of project management and how it works outside peoples' normal thought processes that Berkun challenges the reader with from the beginning.

    Learning From Failure

    Berkun, who openly acknowledges the mistakes, failures, and challenges of his time at Microsoft is clear that organizations need to dissect every project after the fact so that lessons can be learned and applied. Throughout the book, he also emphasizes the importance of planning and setting realistic milestone schedules that can react easily to changes without major impact. The author then leads the reader through each step of the project life cycle, interjecting thoughtful discussion and not just rigid "book rules" and theories. He acknowledges the place of theory, especially in decision making, yet shows their limits when it comes to real life, time-constrained decision making.

    For this reader, the biggest strength of the book is its continual focus on the human dynamics associated with communication, leadership, and politics surrounding. Berkun argues that unless these are mastered, any project is doomed to failure.

    Who Should Read This Book?

    This book should be read by any system administrator or application developer involved in any size project. It should be read by people who want to be or are program managers, It should be read by those who manage project managers. And finally, it should be read by information technology compliance and governance professionals from two perspectives. The first is two understand the dynamics of project that pose governance challenges. the other is to see how they can apply the principles to their governance implementations.

     

     

    ...


    Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

    Last modified: June 05, 2008