• Advertisement
Sign in to follow this  

Fixed Scheduling vs Adaptive Scheduling?

This topic is 457 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi folks,

 

I've recently just finished up with a 3 month project on my university course where I had to manage a team of 5 students. To begin with we set out and roughly scheduled the main development segments in MSProject with tasks for each week as best we could. However, as development got more underway I felt most of my time was spent adapting the schedule to accommodate time differences and new aspects that were added/not thought of. This lead me to focus my attention to having weekly adaptable scheduling through Trello so that I could spend more of my time involved with the team members on the project.

 

Do you guys believe it is better to stick the original method and be able to mark changes for improving scheduling estimates? Or perhaps be more flexible with schedules with more adaptive and transparent tools for the team? Or perhaps just a hybrid of both?

 

Any feedback would be greatly appreciated, thanks. 

Share this post


Link to post
Share on other sites
Advertisement

Sounds like you just discovered Agile development. In theory this is an effective way of managing a project where the requirements are subject to change and estimates are necessarily imprecise. In practice I find it's often used as an excuse to not really plan things properly.

Share this post


Link to post
Share on other sites

Appreciate the quickly reply Kylotan, 

 

In practice I find it's often used as an excuse to not really plan things properly.

 

So in essence the adaptive and flexibility of using tools like Trello is effective but don't disregard setting out the foundations of a schedule plan early on to aid in risk and time management? 

Share this post


Link to post
Share on other sites

Using agile is great for small groups of engineers to manage work in self-organizing teams.  It was invented by engineers for engineers to engineer and it's probably the right rigid dogmatic methodology for something like a small group of engineers in university engineering an engine.  Turns out it's not a good solution for large real-life projects with non-engineer stakeholders and participants (ie. salespeople in suits, pointy-haired bosses, and slack-jawed customers), but fortunately most such projects can be broken into smaller engineering steps (use the levelling tool, Gantt and PERT charts from classic project management to identify these tasks) and those sub-tasks can leverage agile to their advantage.

 

So, probably, the answer for you with the team you described is to do what you did with Trello, and maybe adopt some other agile methods like sprints and scrum and voting on cards.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement