Project Management Central

Please login or join to subscribe to this thread

Topics: Communications Management, Schedule Management
How to bridge disciplinary gaps?
Network:1969



There are few team members in the team who do not respect timelines. They work in their own schedule, do not perform unit testing. So if a bug is resolved, other 2 bugs are opened. And when ever management cross question about this, then just blame to requirements or poor schedule - even if requirements accepted and estimated by the team in first place.
Any suggestions on how to resolve such disciplinary gaps?
Sort By:
Page: 1 2 next>
Network:958



Sonali, I would venture to say that the problem stems from a lack of communication. I've seen in many organization that requirements would be documented and given to the dev team without any discussion (I'm not going to jump on the agile wagon). Typically in these situations estimations were given on best guess and sometime just to get the monkey of my back. In reality however the task might take much longer due to complexity not understood, missing details etc. When they then try to make a deadline under pressure the result is sloppy work and missed deadlines.

So before I look at how to resolve discipline I would try and identify the cause. BTW you might already have done this?
...
1 reply by Sonali Malu
Dec 24, 2018 8:49 AM
Sonali Malu
...
Yes, RCA is done for multiple releases and always found the same cause like under-estimation, no time for req management, etc.
Analysis performed by team and also provided estimates. We decide release date by adding buffer on top of it. Still, the result is always same.. Delayed release and feature takes lot of time for stabilization.
Network:91



These are not disciplinary gaps but normal things that happen in software development especially if Scrum is used and/or the time between software releases is small.

Look at Microsoft Windows, ever since they decided to release a new version of Windows 10 every 6 months almost all the releases were delivered with major defects. 6 months releases are too short for an operating system.

Estimations in software development mean nothing they are just guesses as it is simply impossible to make accurate estimations in this domain. If the management of a software development company does not understand this basic fact then those managers shouldn't have been there in the first place.

Anyway all these issue are not normally the responsibility of the PM but the responsibility of the software development manager and technical management.
Network:167



There needs to be internal timelines for deliverables like by when unit testing has to be complete, adequate documentation of what was tested with results, determine the complexity of the code being newly developed for the project/module/feature, have expert or SME or peer review what was developed/coded along with test results. Have a common agreement of all these practices and timelines and encourage team members to adhere to it.
Also you could have a cutoff of how many bugs can be acceptable considering the complexity of the project /feature and have root cause analysis of why more defects are being introduced when fixing open defects. If things don't work well have management involved in all these discussions to help team members understand the importance of these practices.
Network:664



Yes, this is a common scenario in IT industry. Most of the software developers have the same habit. It is just laziness because there is no action taken. Implement disciplinary actions, practically do the micro management for sometime and once things are on track and resources no longer needs hourly or couple of hours status update then leave them to their own. You need to tighten up the screws sometimes. Also make sure the requirements are documented, discussed, and agreed for scope, timelines and dependencies & constraints. I hope this will help.
...
1 reply by Adrian Carlogea
Dec 15, 2018 7:08 PM
Adrian Carlogea
...
It is not the job of the PM to "discipline" employees this is the responsibility of the functional manager. In the majority of cases the software developers and the software developing project managers are at the organizational level peers which means that the PMs don't have the authority to discipline developers.

Software development is a creative activity and because of this, unless we are talking about trivial tasks, it is impossible to give accurate estimates. Also bugs are inevitable no matter how many unit tests you are writing. Probably Microsoft developers do write unit tests but ever since the release cycle for Windows has moved to 6 months the system has had a series of sever bugs. It is much worse than previous systems that had a much longer release cycle.

In some cases developers do have to be disciplined if they don't perform their job properly but missing dead-lines or producing many bugs is not a criteria for determining that the developers are negligent. You need managers with technical background in software development to determine this or other mechanisms that exclude the opinions of the people that have never written a line of code in their lives.

You need to get your hands dirty in software development and get to a reasonably good level before you can understand these things.
Network:1714



First, let me say that being the head of an initiative has an "art" component which is to transform a group into a team, where team is people aligned to get a common objective. Second, if there is a group of people that behaves in a way that is not the needed to be part of the team the head of the initiative must understand why and if there is a reason that is impossible to solve then those people must be out of the team. Third, whole company is involved on each person behavior and belief (thing that are components of company culture) so before to take a decision the unit in charge of manage this type of things has to help you. And at the end, when I worked into a company that used a system of annual objectives to decide the yearly bonus then for those people some objectives relatated to the way it is needed as behavior were stated into the annual objectives.
Network:82



I agree with Ajay here in a way.

That being said, you can ask EOD status by sharp 6 PM or so and basing on that, you can pose questions to them.

When I asked status in a company where I was working, they said, earlier managers( before me) never asked!!!. I told them that till I get a better handle, I needed it. So it took couple months.
...
1 reply by Sonali Malu
Dec 24, 2018 8:54 AM
Sonali Malu
...
Also tried this micro management in few ways. But they'll make an excuse and leave, actually don't respect timelines and don't own the deliverable.
Network:568



I would suggest that UAT be part of each sprint, and only after passing UAT would the sprint deliverables enter the integration testing (final testing) before release. If they don't complete their UAT then the entire team will be held responsible for not meeting the goal of a working release by the end of the sprint. When others who are doing things the right way learn of the problems in the group they should self police, or all fail together. Sometimes failing is what's needed. Unfortunately, sometimes things get worse before they get better. :/

jtf
Network:4919



Lots of factors should be considered. nature of project, organization, a structure of project and organization, administrative policies, HR policies, etc. However, motivating the team is one of the most important roles of a project manager.
Network:1225



Sonali -

A few other ways to address potential lack of quality or discipline on the part of individual team members include:

- having the team define working agreements
- having the team define a Definition of Done for work items
- non-solo work (e.g. pairs programming)

Kiron
Network:91



Dec 14, 2018 4:37 AM
Replying to Ajay Dixit
...
Yes, this is a common scenario in IT industry. Most of the software developers have the same habit. It is just laziness because there is no action taken. Implement disciplinary actions, practically do the micro management for sometime and once things are on track and resources no longer needs hourly or couple of hours status update then leave them to their own. You need to tighten up the screws sometimes. Also make sure the requirements are documented, discussed, and agreed for scope, timelines and dependencies & constraints. I hope this will help.
It is not the job of the PM to "discipline" employees this is the responsibility of the functional manager. In the majority of cases the software developers and the software developing project managers are at the organizational level peers which means that the PMs don't have the authority to discipline developers.

Software development is a creative activity and because of this, unless we are talking about trivial tasks, it is impossible to give accurate estimates. Also bugs are inevitable no matter how many unit tests you are writing. Probably Microsoft developers do write unit tests but ever since the release cycle for Windows has moved to 6 months the system has had a series of sever bugs. It is much worse than previous systems that had a much longer release cycle.

In some cases developers do have to be disciplined if they don't perform their job properly but missing dead-lines or producing many bugs is not a criteria for determining that the developers are negligent. You need managers with technical background in software development to determine this or other mechanisms that exclude the opinions of the people that have never written a line of code in their lives.

You need to get your hands dirty in software development and get to a reasonably good level before you can understand these things.
...
1 reply by Sonali Malu
Dec 24, 2018 8:52 AM
Sonali Malu
...
True, I guess a technical head is needed for the team to review coding practices and to monitor their time as well.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"When one door closes another door opens; but we often look so long and so regretfully upon the closed door that we do not see the ones which open for us."

- Alexander Graham Bell

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events