Software Project Manager's Problem

The Software Project Manger’s Problem: 

 Mangers in an organization are responsible for more than managing 

individual projects. Their responsibility spans the overall organizations life cycle. 

Mangers need to evaluate their organization by comparing it with other, 

competent organizations. Project manager has many tasks, which can be 

summarized as – “Plan the Work and Work the Plan”. 

 One-way of deciding what ought to be covered in ‘Software Project 

Management’ is to consider what the problem are that it should address. The 

software project manger’s primary problem is that a software project needs to 

simultaneously satisfy variety of constituencies the users the customers, the 

development team, the maintenance team and the management team. A 

survey of mangers some year ago identified the following commonly experienced 

problems.

(i) Poor estimates and plans.  

(ii) Lack of quality standards and manures.    

(iii) Lack of guidance about making organizational decisions.  

(iv) Lack of techniques to make progress visible.  

(v) Poor role definition – who does what? 

(vi) Incorrect success criteria.  

To have successful software project, the manager and the project team 

members must know what will constitute success. This will makes them 

concentrate on what is essential to project success.  

Primary job of the software project manger is to make winners of each of the 

parties involved in the software process: the project manger’s subordinates and 

manager’s the customers; the users and maintainer’s of the resulting product; 

and any other significantly affected people, such as the developers or users of 

interfacing products, therefore software project manger’s problem can be easily 

explained.

(A) The maintainer’s of the product desire a well documented, easy to modify 

systems with no bugs.  

(B) The bosses of the project manger desire a project with ambitions goals, 

no overruns and no surprises. 

(C)  The customers desire a product delivers reliably to short schedule and 

low budget.  

(D) The users – sometimes too enthusiastic, sometimes too skeptical – desire 

a robust, user-friendly system with many functions supporting their 

mission.  

(E) Subordinates (Development team members) – often brilliant sometimes 

unmanageable – desire interesting technical challenges and fast career 

paths, generally with a preference for design and an inclination to defer 

documentation.