Managing software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and challenging demands from high-pressure people. Innovation further complicates the field of project management. Iterative design thinking and continuous improvements bring additional complexities to the life cycle, timelines and budgets.
Project management is a juggling act, with too many points of failure and uncertainty. A detailed scope and a plan are not sufficient to ensure success of projects anymore.
Techno-Comp trains its Managers for managing these risks. Learning survival tips from people who’ve already done their tours of duty in the project management trenches can save your projects instead of learning them the hard way.
Techno-Comp creates a culture of mission possible. This begins with ascertaining the following is set as the founding principles of the program.
First, Define success criteria
At the beginning of the project, make sure the stakeholders share a common understanding of how they’ll determine whether this project is successful. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals. Some examples are:
- Increasing market share by a certain amount by a particular date.
- Reaching a specified sales volume or revenue.
- Achieving certain customer satisfaction measures.
- Saving money by retiring a high-maintenance legacy system.
These business goals should imply specific project success criteria, which again should be measurable and trackable. These goals could include achieving schedule and budget targets, delivering committed functionality that satisfies acceptance tests, complying with industry standards or government regulations, or achieving specific technology milestones. The business objectives define the overarching goal. It doesn’t matter if you deliver to the specification on schedule and budget if those factors don’t clearly align with business success.
Second, Identify project drivers, constraints and room for error
Every project must balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds.
Third, Establish project release criteria at the very beginning
Early in the project, decide what criteria will indicate whether the product is ready for release. Some examples of possible release criteria are:
- There are no open high-priority defects.
- The number of open defects has decreased for X weeks, and the estimated number of residual defects is acceptable.
- Performance goals are achieved on all target platforms.
- Specific required functionality is fully operational.
- Quantitative reliability goals are satisfied.
- Specified legal, contractual, or regulatory goals are met.
- Customer acceptance criteria are satisfied.
Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what “quality” means to your customers. (internal and external)
Finally, Negotiate at all times
Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers, managers, and team members to agree on goals that are realistically achievable. Negotiation is required whenever there’s a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates.
Any data you have from previous projects will strengthen your negotiating position, especially because the person with whom you’re negotiating likely has no data at all. However, there’s no real defense against truly unreasonable people.
Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialize, or new requirements are added. No one likes to have to modify his commitments. But if the reality is that the initial commitments won’t be achieved, let’s not pretend that they will right up until the moment of disappointing truth.
Planning a project: Begin with writing a project plan
Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is doing the planning—thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you encounter later in the project. A useful plan is much more than just a schedule or task list. It also includes:
- Staff, budget, and other resource estimates and plans.
- Team roles and responsibilities.
- How you will acquire and train the necessary staff.
- Assumptions, dependencies, and risks.
- Target dates for major deliverables.
- Identification of the software development life cycle that the project will follow.
- How you will track and monitor the project.
- Metrics that you’ll collect and analyze.
- How you will manage any subcontractor relationships.
Your organization should adopt a standard software project management plan template, which each project can tailor to best suit its needs. Advanced planning and creative planners will be essential to manage iterative nature of the project.
Methodology and its Execution Criteria matters
Waterfall, Agile, DevOps, Iterative Design or a hybrid approach – all methods fundamentally require a culture for work groups in a project. Most methods help provide basic guidance to the approach the project at hand. This is evident in enterprise application development and maintenance programs. There are all shades of grey and preference to one method or the other is purely a matter of organizational capability to building a culture.
Business goals must drive selection and adoption of a project methodology. This underscores on how an organization is comfortable conducting its design phase. Execution includes subcontractors willingness and capability to adopt to the overall methodology selected.
Whatever be the project, our founding principles bring several practices that are borne out of our experiences managing a breadth of medium to complex programs.