Best practices for Software Management with respect to social aspect

In this, we will discuss the various practices of Software Management with respect to the social aspect.

Save “lessons learned” info for your projects

Even if there are experienced staff in projects, there may be unforeseen events which may obstruct or retard development process. This can be a complex item configuration, error, production experience etc. Those happenings are highly preferred to be written in “lessons learned” documents and shared in public locations. This will avoid recurrence of time loss and provide more productive software process.

How To Identify & Record Project Management Lessons Learned:

Don’t save it all for the end of the project:
Attach quick review meetings to project milestones to support continuous learning. Periodic reviews are known to have a positive impact on team motivation, since they’ll directly benefit from the lessons learned instead of altruistically passing on tips to other teams. This also means you’ll get better quality insights, as people aren’t trying to remember what happened weeks or months ago. Plus, it’s easy to gather everyone while the project is still active. (This is especially true with contract workers or consultants, who typically scatter once a project ends.)
Focus on why and how: A lessons learned document isn’t simply a report or description of the project’s results. Go deeper: what problems did you encounter and how did you solve them? What cause-effect relationships did you notice? What insights did you pick up into how work processes could be improved?
Emphasize successes: Which strategies and procedures contributed to success? Knowing what worked well is just as helpful as knowing what didn’t! Answer these questions:
- What should we start doing?
- What should we stop doing?
- What should we keep doing?
- What’s still causing us trouble?
Evaluate each stage of the project: If you’re stumped on where to start, discuss these aspects of the project with your team to get the conversation going and make sure you hit all the important points:
- Project planning
- Defining scope & requirements
- Resource and budget management
- Risk management
- Reporting
- Testing/Revisions
- Stakeholder communication
- Team communication
- Quality of meetings
- Quality of final project outcome
Find consensus: Your whole team should agree on the lessons learned, and everyone should contribute. The people personally involved in the work are the ones with the insights you need!
Make takeaways actionable and widely applicable: Once you’ve collected lessons learned with your internal team, you need to repackage them for general use and apply them to your future work. They shouldn’t be so specific that they don’t pertain to new projects, or so generic that they confuse people. Create a preliminary plan: what would improvements look like, and who would be responsible for making them happen?
Make your conclusions accessible: Wouldn’t it be a shame to go through the process of reflecting and recording lessons learned only to have your insights lost or forgotten? Set up a knowledge base or an intranet where every team can store their lessons learned and access advice from other teams.

Define meeting types

Meetings are very important if we are talking about software process management and should be defined in detail (meeting participants context, average duration etc.). Team members should also obey meeting rules. This will bring more productive meeting and development process, and will avoid losing time unnecessarily.

Define roles and tasks of team members

For productivity, roles of team members should be defined clearly. These roles may be project manager, team lead, developer, tester etc. Furthermore, authorizations and responsibilities of these roles should be defined very clearly. Task-assignment based development should also be applied for avoiding redundant efforts and chaos.

Best Practice: In addition to the primary researcher(s), there might be others involved in the research process that take part in aspects of data management. By clearly defining the roles and responsibilities of the parties involved, data are more likely to be available for use by the primary researchers and anyone re-using the data. Roles and responsibilities should be clearly defined, rather than assumed; this is especially important for collaborative projects that involve many researchers, institutions, and/or groups.

Examples of roles in data management:

data collector
metadata generator
data analyzer
project director
data model and/or database designer
computing staff responsible for backup and/or storage
staff responsible for running instruments
administrative support staff responsible for grant submission
specialized skills as defined in the plan (GIS, relational database design/implementation, computer programming of sensors/input forms, etc)
external data center or archive

Steps for assigning data management responsibilities:

For each task identified in your data management plan, identify the skills needed to perform the task
Match skills needed to available staff and identify gaps
Develop training/hiring plan
Develop staffing/training budget and incorporate into project budget
Assign responsible parties and monitor results

Description Rationale: A successful data management plan requires that the appropriate staffing resources are available and trained. Identifying specific tasks and responsible parties will help with budgeting, implementation, and preservation of the data resources.

Related Best Practices: