What Does Good Development Management Look Like?
•Download as PPTX, PDF•
0 likes•410 views
Lee Connor, Technical Director at Catalyst IT Solutions delivered a presentation exploring opinionated views of Development, focusing on project delivery rather than the technical practicalities of developing software.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to What Does Good Development Management Look Like?
Similar to What Does Good Development Management Look Like? (20)
More from Corecom Consulting
More from Corecom Consulting (20)
Recently uploaded
Recently uploaded (20)
What Does Good Development Management Look Like?
- 1. © 2015 Catalyst IT Solution. www.catalystITsolutions.co.uk Lee Connor Technical Director
- 2. Who are Catalyst? Catalyst is an IT services business: CRM, ERP, Financials & HR - Netsuite & Microsoft Dynamics Business Intelligence - Qlik Bespoke Web & Digital Solutions – Microsoft & Open-source / MaaS
- 3. What we do for our clients
- 4. What we do for our clients Catalyst customers benefit from Catalyst’s culture and core values which are based around: Client focus Successful project deliveries Projects with definite customer ROI and a focus on delivering business outcomes A positive customer experience A ‘can do’ culture and a strong work ethic
- 5. Our Promise We make technology work for you by investing our time and expertise to understand your business “ “
- 6. What does good Dev Management look like? Lee Connor Technical Director Catalyst IT Solutions
- 9. Software Dev is like Construction
- 10. Waterfall
- 11. Agile
- 12. One size does not fit all
- 13. Don’t hide behind Process
- 14. Don’t forget you’re a Manager First
- 15. Your Team is King
- 16. And you’re a PM
- 17. Clear Sight of the Project • Problem Blind customers will assume they are about to walk off a cliff
- 19. Understand the Commercials • Problem
- 20. What does good Dev Management look like ? Don’t rely on process Remember its a management role Get close the project and the customer Get visibility of the project Manage change Understand the commercials of the project
- 21. Remember… Don’t be frightened of project plans and mixing methodologies Find a way of working that fits the team and the project Your staff are key, 1 good developer is worth 5 average ones Don’t lose sight of the Customer & Reason for your project Make it real - ensure you understand the impact of overrun and share it with the team Change Control – call out Cost & Time impact Invest in good systems to streamline Stay close to the project and the detail
- 22. © 2015 Catalyst IT Solution. www.catalystITsolutions.co.uk
Editor's Notes
- Opinionated
- Where we have a customer focused project how do you keep quality, flexibility, an original estimate and still deliver on time and on budget We are all here to make money yes ? The customer (int & ext) still wants a quality product on time and on budget, they don’t care about signing a large legally binding scope doc or indeed planning iterations, scrumming and the like. After all we are the experts at delivering software not them… Yes and no: Agile needs a large amount of time for the customer to commit to, great for internal product development not so for fixed cost / fixed time projects Waterfall is great for smaller projects, where scope can be pre-determined and enfouded
- If you need to deliver in time and in budget then you have the development problem There is no silver bullet, golden gun… blah blah There is no one way to deliver a flexible process, by nature projects are flexible So what is the answer That depends, you need to mix the two that works to your customer and your needs and even projects Some projects can be flexible, keep pre-specification short and work closely with the customer Some projects with high risk will need pre-planning and estimation with a large enough contingency to cover your potential problems This is where a development manager you earn your money
- Organising multiple people with multiple jobs And just like construction things and do go wrong that cannot be predicted
- Waterfall projects are easy to PM from a none technical – Prince 2 type For IT projects this simple does not work the majority of the time However they are easier to estimate and a publish known end date and cost can be provided
- Agile projects are the holly grail of project development Lots of flexibility Difficult to tie down a final budget and time for delivery IT development teams love this as they cannot be pushed for delivery High level of customer interaction is needed
- Need to be pragmatic approach to delivery Don’t follow the book to the letter of the law
- Do not let you or your team get embedded into one way of working The classic approach of use agile as an excuse for the lack of: Planning Good process Discipline But have good solid process and tools to mange the day to day Requirements / scope capture Design and peer review process and documentation Change control Dev Test process Bug tracking & client interface / management tools And ensure everyone knows how your working and why – including the customer!
- Think you’re a manager first Get the best our of your team Trust your team They need to trust you Don’t treat your team with respect and they will respect you Once you have build a good team – keep it Remember – a good developer is worth 5 average ones !
- Empower your team Allow the team to construct and change process Communicate the detail of the project Don’t protect them to much Let them know some of the commercials to make the project real This will get buy in and a team mentality
- Support the PM Sometime we do need to work with the none technical PM Step up and become the Technical PM, right hand man of the PM Yes this will be painful but necessary for a good quality delivery
- Good communications Good relationship Have the open view of project together Will make identifying and making changes to the project much easier Have a milestone plan Have highlight reports
- Change is always a funny in software development You should have the relationship to perform change and adjust the timeline and more importantly scope and cost If you can’t have that conversation with the customer – your doing something wrong Don’t blame the customer for brining up issues to late Ask questions early - use your experience to expect change / updates
- Don’t rely on a logical and structured development systems to manage a variable process of scoping and unknown bugs and issues Don’t use contingency as a buffer to make people feel comfortable Use change control’s to manage scope movements and re-plan according Yes this is waterfall, but none technical can visualise the changes and the impact Remove the ‘magic‘ from development Progress can be shown and identified Re-planning and re-cutting a plan can help refocus the team and project
- With time and effort, you can track your developers, allowing an true estimation % to be calculated As development managers your manager of people first and foremost Get close to your team and the projects Milestone plans … Iterations Scope Flexable Change controls Profitable projects.