As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the difference between project management and process management?
The defining characteristic of process vs. project is repeatability vs. uniqueness.
Process is a repetitive collection of interrelated tasks aimed at achieving a certain goal.
Project is a unique endeavour with a beginning and an end undertaken to achieve a goal.
Process management has emphasis on increasing "repeatability" of the tasks, efficiency (descreasing time needed, reducing cost), increasing quality (including consistency in quality).
Project management has emphasis on getting the thing done, achieving the end result. Higher efficiency is harder to achieve since it might require custom tools and methods that can only be developed if the project was turned into a repetitive process.
Applied to software development making a daily build is a process:
It's a sequence of tasks aimed at end result.
The sequence is repetitive.
Tasks are known on the outset, since the process is repetitive.
When managing daily builds we want them to be cheap, fast and consistently meet quality standards, in most cases this is best achieved through increased automation.
Designing a new feature is a project:
The feature is unique, once we've designed it we won't be designing it again. Maybe version two, but its going to be a different endeavour.
At some point we need to stop designing the feature (even when its far from perfect) and it is best if we stipulate in advance how do we know that we've reached that point.
We're not as much concerned with that the design is achieved though the most efficient sequence of steps, as with actually coming up with a sufficiently good design at the end.
Hence the sequence of tasks that goes into design will be hard to automate and we need to concentrate on keeping the bounds, re-evaluating criterias, adjusting for newly discovered facts and generally moving the entire thing towards completion.
We have to constantly select from an increasing number of possible tasks that come up in the light of newly discovered facts and pick these that will take us closer to the goal.
Process management would be management of a process, such as a software development process (note that I did not say "software process"). Such a process might be used across a variety of projects. A process does not have an end-product, beyond itself.
Project management would be management of a project, typically using some process, and resulting in a product, or a new version of a product.
If project is work that needs to be done to make an end result, be it a product or a service, then the process is the description of that work. Every project follows a process, even if not formally defined. By attempting to capture that process for each and every project a pattern will emerge that a similar process is being used for certain group or type of projects. It may also be shown that certain process leads to a better end result or leads to the end result faster and/or cheaper. Such process then may be adopted to be used for pertinent projects resulting in higher productivity and quality of end result.
Consequently project management is application of the process to make an end result. There is no process management, just process development, implementation, measurement and improvement which in themselves are projects. Chicken or egg if you please.
Process is an abstraction of project. It is used to generalize the variation,uniqueness and transient nature projects.In order to enhance efficiency,productivity,effectiveness and value of product expected or achieved from a project,the implementation strategy or workflow mechanism for projects is analyzed with the help of process and/or processes.The goal of process is service while goal of project is a product.Process seek long term goals but project aim for short term goals.Project needs are based on end product but process needs are based on process itself.
The one sentence summary is process management manages how projects are generally run and has no deliverables other then documents explaining the process while project management is managing a project to insure that deliverables are created on budget and on time while following what ever process has been created through process management.
Process is basically the part of the project. process means certain rules has been followed
for accomplishment of some task where as project means getting the things done by applying certain process
Well said the above one, the Process management defines the complete process of existing projects as documentation and give a status report to superiors. Even, they plan accordingly for the resource planning in their absence.
The defining characteristic of process vs. project is repeatability vs. uniqueness.
...best description I've ever heard. A poor analogy might be a process is like a day job, a project is like a contract.
In laymans terms a process is a bunch of tasks that need to be performed again and again to keep your organisation running. These tasks may be performed manually (by people in their day jobs) or automatically (by IT).
The eTOM Business Process Framework (www.tmforum.org) says there are three types of processes:
Strategy, Infrastructure & Product Lifecycle Management - a complicated way of saying all the tasks an organisation needs to do to plan for and build new stuff
Operations - all the daily tasks to keep things running & keep your customers happy
Enterprise Management - the rest... Like financial reporting, and so on
Project is a unique endeavour with a beginning and an end undertaken to achieve a goal.
....guru
In laymans a bunch of tasks that you only perform once to build, change (or remove) your organisations capability (eg. it's infrastructure or products).
How are they the same
To add a little more confusion to this dynamic, project management is a process in itself (see PRINCE2 www.prince2.com)
It would fit in the (1) Strategy, Infrastructure & Product category (sorry for flogging eTOM, there's plenty of other frameworks like ITIL and SCOR, I'm an EA at a Telco so its the framework I understand the best.)
Whilst each project has a start and finish date - chances are your organisation is forever building & changing is capability (infrastructure & products). So each project delivers something different but the steps, or bunch of tasks performed, to deliver the project should be the same each time (again see [PRINCE2][2]).
Related
What is the key difference between agile and Incremental and waterfall models?
As a beginner software developer what model should I follow?
I need to be clear.
In addtion to the Gishu's answer
Incremental - you build as much as you need right now. You don't over-engineer or add flexibility unless the need is proven. When the need arises, you build on top of whatever already exists. (Note: differs from iterative in that you're adding new things.. vs refining something).
Agile - you are agile if you value the same things as listed in the agile manifesto. It also means that there is no standard template or checklist or procedure to "do agile". It doesn't overspecify.. it just states that you can use whatever practices you need to "be agile". Scrum, XP, Kanban are some of the more prescriptive 'agile' methodologies because they share the same set of values. Continuous and early feedback, frequent releases/demos, evolve design, etc.. hence they can be iterative and incremental.
Waterfall involves discrete development stages: specification,
design, implementation, testing, and maintenance. In principle, one stage must be
complete before progress to the next stage is possible.
Selecting a process is difficult sometimes.Choosing the right Software development life cycle model Read this article it is helpful.
Waterfall is sequential while agile is an incremental approach.
Waterfall: Conception, initiation, analysis, design, construction, testing, implementation and maintenance. All eight steps will be done in sequential manner (one after another). Once a step is completed, you can’t go back to the previous step. If you make a little change, the whole project will start from zero. So, there's no room for error or change.
When to use waterfall:
If the client has complete knowledge of what they want (size, cost & timeline of project), then go for waterfall.
Advantages:
If any employer leaves the job, the new employer will suddenly grip down the project as all the steps are sequential, so new resources will easily understand the current situation of the project.
Client knows what the final product will look like.
Disadvantages:
If one step is completed, you cannot go back.
Waterfalls demand heavy initial requirements, false requirements will lead your project to somewhere else, not to destination.
If any error is found or any change needs to be made, the project has to start from the beginning.
The whole project is only tested at the end, if bugs are written early but discovered late, their existence may have affected how other code was written.
Agile: Developers start with simple design and then begin to work on small modules. The work on these modules is done on a weekly or monthly basis. After completion of a module, module sent to testing phase, and if any bug comes, then developer first removes that bug and then result is deployed in order to take client review, if client demands any change then first developer has to implement that change. At the end of each module, project priorities are evaluated, on which module we should start work.
When to use agile:
When rapid production is more important than the quality of the product.
When there's no clear picture of what the final product looks like.
Advantages:
Each module is tested after its completion that trains developers not to make such mistakes in the next module.
Agile allows developers and clients to add change at any time.
After each module, the client reviews the application, so the client knows about the progress of the project after each module.
Disadvantages:
It highly demands the successful project manager. As making modules, prioritizing them and setting time period of a module really requires a lot of experience.
As no one has initial requirements, so the final product can be grossly different than what was initially intended.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We just started to use scrum for our project management. We are a very small team (2 developers, 1 UI/Web-deisgner ) and we have a lot of running projects at once.
How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently?
edit: Don't be fixed on scrum. we are a small structure and very flexible with that. Scrum was just my starting point. If you have others systems that worked good for a or your small team i am totally open to any kind of input.
AFAIK the foundation of Scrum is that the team is involved in a single project at a time. Regardless of methodologies, task switching overhead makes it very inefficient to work on multiple projects "in parallel".
What you could do is to try to schedule the different projects into separate sprints, i.e. do a sprint dedicated entirely to project1, then the next sprint entirely on project2 etc. If the projects are of very different scope, you could consider varying the length of sprints, e.g. do a 3-week sprint on a large project, then maybe a 1 week sprint on a small one.
In pure Scrum the length of sprints is carved in stone indeed, but then again, IMO the point is not to get the "pure Scrum implementor" badge, rather a working real-life process for your team.
(disclaimer: I am not a Scrum master :-)
Update based on comment: I see your problem. You need to respond fast to small support (improvement / bug fix) requests from customers of other products, while still need to work on a bigger project in a predictable fashion.
One possibility would be to plan the sprints of the big project in Scrum, but "timebox" some of your time for incoming support tasks. E.g. if on the average you spend 5 days in each monthly sprint supporting other projects, you allocate 5 days' worth of resources (however you count time) for support in each sprint.
Another option may be to consider other methods, like Kanban, where there is no sprint or planning, instead the team works solely (or mainly) based on demand from customers.
You need 1 week sprints. 1 project only per sprint. It is a fallacy that you can deliver software faster by working on multiple projects at once. The bigger project may take several sprints to develop a release where as with your small ones, you may release after every sprint.
If your projects are for different POs / Clients it is even more important that you only work on one at a time; otherwise your priorities will almost always be in conflict.
How do you handle having multiple projects running at once in the scrum model? Most of the time we have a main projects and some small ones. How do you combine multiple sprints efficiently?
One option is to run multiple sprints in parallel and, even if it's not ideal, to be part of several teams (obviously not 100% dedicated). I'm not sure this would make sense in your context though, I'm not convinced running the small projects with Scrum adds value.
Another (maybe more appropriate) option would be to have an item in your product backlog for the work required by satellite projects/tasks and thus to allocate some time for them. If you need that time, burn it. And if not, just pick up some extra backlog items from the main project at the end of the sprint.
If you have a lot of small jobs which have to be done quickly then project management is not the right paradigm. What you are dealing with is operations management which, generally, involves well-defined tried-and-tested off-the-shelf work procedures. I suggest, therefore, that you separate, management-wise, those activities of yours which require project management and those which require operations management. If you do not have the work procedures defined (and tried and tested etc) yet, then you may have to set up a project to develop them (or to codify them if you want to think of them that way).
There is a big difference between the way in which software development projects are (or ought to be) run, and how, say, a help-desk runs. Just because you are a software developer experienced in the project-management paradigm (as I think most of us are) doesn't mean that it is the right approach for everything.
Once you've made the shift, you should find that you can continue to scrum-down (or whatever the term is) on your 1 or 2 projects, and turn the handles on the machine to deliver the rest.
Tricky. Your situation may not be a perfect match for Scrum but I think there are elements in Scrum that are applicable to you situation.
For example, the one thing that I find the most useful in Scrum is the Retrospectives since it is in those sessions where you improve the way you work. However in order to make the Retrospectives useful you need to measure the work you are doing to some set of items that you set out to do. So why not have something similar to sprints and do sprint planning for the items that you intend to do the next 1-2 weeks (shorter weeks seems to be more appropriate for your case). Do a daily Scrum meeting so that all three of you know what the others are up to and can fill in as appropriate. Then after the sprint you can sit down and think about how you can improve. If nothing else, the outcome of the Retrospectives will tell you if this worked for you or not.
I don't believe in trying to adapt a strict Scrum project scheme if that means running sprints in parallel or do shorter sprints with only one project at a time leaving the others untouched every other week.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to determine some of the markers that indicate a project of limited resources.
In my experience a project becomes a ‘limited resources’ project because someone was desperate to sell a solution to a client. The results is a tight budget, features are culled and SDLC processes are cut to a minimum. These short-cuts are taken so the company has some chance of making a profit or even breaking even.
This is a list of things which I have seen go hand-in-hand with a project of limited resources:
Bare minimum amount of time allotted to QA
Strict bureaucratic process for off-spec work
Change request budget may be small or non-existent
Formalised processes get dropped in favour of using time for development
No time available for value-add QA like content checking (e.g. grammar or spelling errors in text).
Can’t do any content management or data entry for client
Have to go for ‘good enough’ coding solutions
No time allowance for hallway usability testing.
no budget for writing user documentation or manuals.
Generally no time for technology research before coding
No time to produce a risk analysis document
A production check-list may be used instead of a project schedule.
The is no time for a programmer to fill their ‘actual’ times vs. estimated times in the project schedule.
Progress updates given to clients may be less frequent or very basic
Less time is available to spend on understanding the clients business domain
Programmers may have to work unpaid overtime.
No time allotted for a project post-mortem
What other sure signs are there for a limited resources project?
===
EDIT
i will try clear up some of the confusion with an example. this is what i mean: the client is given a proposal/quote saying their project will cost $20k. the client then comes back and says "sorry, my budget is $16k maximum". the boss says "make the proposal $16k - we want this work".
so, effectively, you have to do a project with less budget then it should have. there are boundaries where it becomes ridiculous - if the client was to say "my budget is $4k" then you couldnt possibly do it.
and yes, sometimes a tight budget can become so silly that it was a bad business decision to accept the project in the first place (i.e. doomed project).
i understand that there is no such thing as a project with unlimited budget. often business people make the decision whether a project should be undertaken (a business person often isnt a project manager).
What you are talking about is not a 'limited resources' project, but instead a rushed and unplanned project.
A few items in your list I take issue with:
Strict bureaucratic process for off-spec work
Change request budget may be small or non-existent
Actually, these should be the norm for most projects. Who's requesting and paying for the changes, you or the client?
Can’t do any content management or data entry for client
No budget for writing user documentation or manuals.
If that's not part of the contract, why are you doing it?
Have to go for ‘good enough’ coding solutions
At some point, you have to stop at 'good enough', or else you are going to be polishing from now until the end of time.
Something I would add to your list are:
Office supplies become scarce or go under lock and key.
Corporate supplied food/beverages disappear
Down time disappears. 100% of your time on your time sheet must be dedicated to project work.
The printer/photocopier is running full-bore printing other staff member's resumes.
The Boss' door is shut for 90% of the day.
Quite frankly, I've never heard of a project that had unlimited resources. Even the government will put the brakes on something after a while.
So, from a pure logic perspective, all projects have limited resources.
Limited resources? All projects that I know of have limited resources:
time
developers
budget
Outdated or obviously beta documentation which doesn't jive with whatever release of the product on site, or documentation which looks like it's been down through several generations of Xerox copies.
No onsite installation or support. Depending on the size of the system being implemented, a company in good shape might send one or more of their developers to oversee the implementation, whereas a company that's tight might offer phone or email support only in a more "fire and forget" approach.
Continuous occurences of new,
forgotten features, assumed as
"obvious" and "implicit" by the user,
never stated in the requirements,
leading to discussion Bug vs. Change
Request.
Waterfall model adopted instead of an
iterative approach.
Customer protesting on the costs of
fixing, saying something like: "If
you have bugs, it is because you
didn't do your job right", not
accepting the tripple constraint
effects on quality when cutting
time/budget.
Pressure for lower prices for
maintenance and support activities
after project deployment in
production.
Pressure for adopting a fixed-price project (outsourcing) to transfer financial risk together with timeline risk.
"Under-priced projects"
If I understand correctly what you mean, you really are talking about projects where the resources available to the project are not appropriate to achieve the results that were promised to the client.
I can think of four ways for this situation to arise:
Wrong estimates when preparing the project plan
Requirements creep
Reducing the project budget without reducing the project scope
Inadequate resources (staff skills, computer resources, etc.) for the project scope
When people in the project become aware of the situation, they really have two options: cut costs or cut scope. Cutting the scope can be a hard sell and may endanger the project viability, so most of the time people opt for cutting custs, especially since cost can be cut in many ways without atracting the attention from the higher echelons:
Unpaid overtime
Reducing quality
Eliminating documentation
and so forth.
In fact, you may even look good as a project manager when you start cutting costs, since cost containment is one of the project manager's responsibilities! I assume that what you want is to find ways to diagnose an under-funded project. I think that instead of developing an extensive list of symptoms, I would strive to identify a general condition.
In my opinion, there is a general condition that allows to pinpoint an under-funded project. For most projects, staff is the biggest cost - or at least the second biggest cost that can be managed by the project manager. Whenever you find an experienced manager taking measures to reduce staff costs and those measures were not part of the original plan, then you can be sure you have an under-funded project.
Regards,
using the information you guys so kindly contributed i was able to pull it all together and write an article
ill put a link here in case someone in the future is looking for help on the topic:
Surviving An Under-resourced Project
--LM
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Has anyone used the kanban method for software development management?
I am evaluating kanban as a technique and would be curious to hear from anyone who has actually applied it in practice as to how effective it is. I've seen questions like: is-anyone-using-kanban, kanban-vs-scrum, and apply-kanban-in-an-agile-team but they don't address my concerns.
What I'm interested in specifically is:
Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?
Is it easy to execute in practice, or does it have logistical challenges that you need to manage?
Does it scale well to project teams with many parallel streams of work and many developers?
How does it compare to critical path analysis (as implemented in MS Project), how is it different?
What other benefits can be gained from applying kanban?
Thanks.
The Kanban method is foremost a catalyst for continuous process improvements. It’s not a quick fix or a fixed set of steps/practices. The method has a few foundational principles and core properties, as described in David J Andersons recent blog post, that can lead you the way to continuous process improvements.
To your questions:
The Kanban method in itself does not identify bottlenecks. When implementing work-in-progress limits to a process that creates stress on your process you will eventually create a pull system and then it becomes easier to identify bottlenecks in your process. Tools like a visual kanban board and Cumulative Flow Diagrams will help you identify the bottlenecks in the process.
If you apply the foundational principles and core properties and you have the stamina/patience/dedication it is not too hard. You need to manage the change process as with every organizational change but the Kanban Method is designed to make small and non-threatening changes.
Yes there are many documented cases of this.
The Kanban method does not identify a specific method for planning and projecting future deliveries. David J Anderson has a background in Theory of Constraints and uses TOC as a model in most of the writing I have read. I think the practical difference between using MS Project style big up front planning and the empirical based planning used in many kanban implementations is the big difference. When working with a project plan designed in MS Project in the beginning of a project you know very little of the actual problem domain and you make assumptions. Based on these assumptions you device a plan. A critical path is calculated based on these assumptions. With a stable kanban system and you use TOC as your model you plan “only” to have your constraint/bottleneck on the critical path. You take into account the historical variability of the work passing the constraint and you create buffers around you bottleneck with the appropriate risk you want to take. The thinking is that every hour lost at the bottleneck will be an hour lost for the whole system.
The main benefit of the Kanban Method is that it is a catalyst for continuous process improvements. It starts with what you got and makes non-threatening changes that sticks. Kanban is a method that is Made to Stick
In the article Applying Kanban to PC Deployment the Team has to account for the following equipment:
160 new PCs to be deployed
40 new laptops to be deployed
120 PCs and 10 laptops to be refreshed and redeployed
... we are exploring the use of Kanban to manage a short-term functional
project. This example focuses on using Kanban to create a transparent
process to track the flow of equipment through a number of complex
steps, without incurring additional costs for tracking software,
complex processes and training, or duplication of effort. Improved
uniformity or quality of the deployment process will also help improve
efficiencies in troubleshooting and repair times as well as ensure a
document-ably high level of conformance to software and licensing
standards.
The page above has also links to Kanban applied ...
to Tech Support
to PC Deployment (see Quote above)
to a Development Group
Challenges, Additional Concepts, and Wrapup
I also don't have a lot of experience with it, but I think I can offer some insight.
1 & 4: the main difference between Kanban boards and other techniques, like CPM, is that a Kanban board, in a correct implementation, forces you to impose work-in-progress limits. This creates a pull system, since new items are accepted by workers only when they have capacity. This differs from an MS project type project where tasks are assigned to workers before-hand (i.e. pushed).
It is much easier to identify a bottleneck in a pull system, because work items will be queuing up at some stage in the process. In a push system, work is pushed through the system (whether it is 'done done' or not), so its difficult to find bottlenecks.
Another advantage of a pull system is you can start to base work timelines on actual results (lead and cycle time), as opposed to prediction. Yes, the size and granularity of stories does affect this, but with techniques such as cumulative flow diagrams this becomes less important.
2: Most implementations are pretty simple, and therein lies some of the strength of the technique. I think if you're having problems with the logistics of the technique, you're doing it wrong. Have a look here for a nice 'kickstart example'.
Few definitions to focus on before jumping onto the differences:
Agile – A structured and iterative framework to track and manage projects. This approach is used in managing software development projects. It allows cross-functional teams to collaborate on users expectations.
Kanban – A framework which utilizes visualization technique, limiting the number of tasks to be taken in “Work in Progress” column. The segregation of a similar type of tasks can be done here. To simplify it, allocate colors to tasks using the swim lanes.
Scrum – The approach followed here is breaking down a complex task into simpler smaller manageable pieces which are easy to collaborate upon by the respective owners of the [scrum][1].
Similarities between Kanban and Scrum
Frameworks of agile methodologies
Used to track the progress of the project
Provide the team transparency in tracking the work progress
Make use of visualization
Differences between Kanban and Scrum
Roles – Scrum is dependent on the scrum owners and is worked upon by them respectively. Kanban is independent of cross-functional team members and parallel roles.
Release cycle – Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Kanban does not follow any cycle and the process is continuous in nature.
Tracking parameters – Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint. Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.
The scope of improvement – Scrum does not encourage changes in ongoing sprints. Kanban is open to any changes before the completion of the project. It is flexible in nature.
Fit factor – Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit. Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.
Pick process – Scrum picks the entire batch of user stories from the product backlog for development. Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.
Delivery – Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.Kanban follows the continuous delivery model based on business needs.
The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.
I don't have specific experience with using Kanban in software but I am familiar with the practice from a manufacturing point of view, so I was curious as to the implementation. Reading your link, the thing that struck me as a possible hitch is what felt like an underlying assumption about the same-sized ness of the units of work (features, stories, whatever). While keeping things "story sized" is a good goal, there are often mixes of bigger and little stories floating around, and the small number constraints in their pipeline therefore seem artificial. If the goal is to highlight bottlenecks, I would think that stand ups and sprint planning and retrospectives will do that well enough. If the goal is to facilitate prioritization, I think that putting constraints on numbers of tasks by types wouldn't do that as well as simply ordering them top to bottom.
I guess I don't really see what value its adding; that being said, I don't see the harm in trying it and adopting whatever pieces work.
1. Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?
This has been my experience. By setting your WIP limits to reflect available capacity, if there is work that needs to make use of that capacity but has to wait for it to become available then you will see it as the queue of work backs up ahead of the bottleneck. I have seen this happen when there is an overworked QA team with an upstream development team who keep producing even though there is no chance of it getting looked at by QA. The solution we took to this was to lend some of the developers to the QA team who then helped alleviate the bottleneck.
2. Is it easy to execute in practice, or does it have logistical challenges that you need to manage?
This will depend on many factors which will be specific to the context to which you are applying it. One of the great strengths of Kanban is it does not require an immediate 'all or nothing' change from how you are currently working. The chapter 'A Recipe for Success' in David Anderson's 'Kanban' book gives a great way of approaching the change, starting with 'Focus on Quality'
3. Does it scale well to project teams with many parallel streams of work and many developers?
In the project where I first used it we ended up with a team of seventeen developers and we had moved the QA team of four into our team too. We also had lots of external dependencies which we used Kanban to model.
4. How does it compare to critical path analysis (as implemented in MS Project), how is it different?
Pass as have never used
5. What other benefits can be gained from applying kanban?
There are many but the one I will call out is that it gives you metrics that are genuinely useful for discussing and steering the work, both with the team and with stakeholders and other people outside the team. Specifically the use of 'Throughput' and 'Cycle Time' help give you a probabilistic for cast of when work will get done.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have two projects, with identical priorities and work hours demand, and a single developer. Two possible approaches:
Deliver one project first.
Split the developer's time and deliver both later.
I can't see any reason why people would choose the second approach. But they do. Can you explain me why?
It seems to me that this decision often comes down to office politics. One business group doesn't want to feel any less important than another, especially with identical priorities set at the top. Regardless as to how many different ways you explain why doing both at the same time is a bad idea, it seems as though the politics get in the way.
To get the best product to the users, you need to prevent developer thrashing. When the developers are thrashing, the risk of defects and length of delivery times begin to increase exponentially.
Also, if you can put your business hat on, you can try to explain to them that right now, nobody is getting any value from what the completed products will deliver. It makes more sense for the business to get the best ROI product out the door first to begin recouping the investment ASAP, while the other project will start as soon as the first is finished.
Sometimes you need to just step away from the code you have been writing for 11 hours in order to stay maximally productive. After you have been staring at the minutiae of a system you have been implementing for a long time it can become difficult to see the forest for the trees, and that is when you start to make mistakes that are hard to un-make.
I think it is best to have 2-3 current projects; one main one and 1-2 other projects that aren't on such a strict timeline.
If both projects have the same priority for the company, one obvious reason is for project managers to give higher management the illusion that both of the projects are taken care of.
Consider that the two projects could belong to different customers (or be requested by different people from higher management).
No customer wants to be told to wait while a different customer's project is given priority.
"We'll leave the other one for later" is, a lot of times, not an acceptable answer, even though this leads to delays for both projects.
I believe this is related to the notion of "Perceived Responsiveness" in a software program. Even if something takes more time to do, it looks faster when it appears to be doing something, instead of idly waiting for some other stuff to complete.
It depends on the dependencies involved. If you have another dependency upon the project that can be fulfilled when the project is not 100% complete, then it may make sense to split the developer's time. For example, if your task is large, it may make sense to have the primary developer do a design, then move on to a second task while a teammember reviews the design the primary developer came up with.
Furthermore, deserializing developers from a single task can help to alleviate boredom. Yes, there is potentially significant loss in the context switch, but if it helps keep the dev sharp, it's worth it.
if you go by whats in the great and holy book 'peopleware', you should keep your programmer on one project at a time.
the main reason for this is that divided attention will reduce productivity.
unfortunately, because so many operational managements are good businessman rather then good managers, they may think that multitasking or working on both projects somehow means more things are getting done (which is impossible, a person can only physically exists in one stream of the space-time continuum at one time).
hope that helps :)
LM
I think the number 1 reason from a management standpoint is for perceived progress. If you work on more than one project at the same time stakeholders are able to see progress immediately. If you hold one project off then the stakeholders of that project may not like that nothing is being worked on.
Working on more than 1 project also minimizes risks somewhat. For example if you work on one project first and that project takes longer than expected you could run into issues with the second project. Stakeholder also most likely want their project done now. Holding one off due to another project can make them reconsider going ahead with the project.
Depending on what the projects are you might be able to leverage work done in one for the other. If they are similar then doing both at the same time could be of benefit. If you do them in sequence only the subsequent projects can benefit from the previous ones.
Most often projects are not a constant stream of work. Sometimes developers are busy and sometimes not. If you only work on 1 project at a time a developer and other team members would likely be doing nothing while the more 'administrative' tasks are taking place. Managing the time over more than one project allows teams to get more done in a shorter timeframe.
As a developer I prefer working on multiple projects as long as the timelines are reasonable. As long as I'm not being asked to do both at the same time with no change in the schedule I am fine. Often if I'm stuck on one project I can work on the other. It depends on the projects though.
I'd personally prefer the former but management might want to see progress in both projects. You might also recognise inaccurate estimates earlier if you are doing some work on both, enabling you to inform the customer earlier.
So from a development perspective 1 is the best option but from a customer service point of view 2 is probably better.
It's managing your clients expectations; if you can tell both clients you are working on their project but it will take a little longer due to other projects then to say we are putting your project off till we finish this other project the client is going to jump ship and find someone that can start working on their project now.
It's a plaecbo effect - splitting a developer between two projects in the manner you've described gives people/"the business" the impression that work is being completed on both projects (at the same rate/cost/time), whilst in reality it's probably a lot more inefficient, since context switching and other considerations carries a cost (in time and effort).
On one hand, it can get the ball rolling on things like requirement clarifications and similar tasks (so the developer can switch to the alternate project when they are blocked) and it can also lead to early input from other business units/stakeholders etc.
Ultimately though, if you have one resource then you have a natural bottleneck.
The best thing you can do for that lone developer is to intercept people( from distracting that person), and try to carry some of the burdon around requirements, chasing clarifications and handling user feedback etc.
The only time I'd ever purposely pull a developer off their main project is if they would be an asset to the second project, and the second project was stalled for some reason. If allowing a developer to split a portion of their time could help jump-start a stalled project, I'd do that. This has happened to me with "expert" developers - the ones who have a lot more experience/specialized skills/etc.
That being said, I would try to keep the developer on two projects for as little time as possible, and bring them back to their "main" project. I prefer to allow people to focus on one task at a time. I feel that my job as a manager is to balance and shift people's priorities and focus - and developers should just develop as much as possible.
There are three real-life advantages of splitting developers' time between projects that cannot be ignored:
Specialisation: doing or consulting on work that requires similar specialised knowledge in both projects.
Consistency and knowledge sharing: bringing consistency into the way two separate products are built and work, spreading knowledge accross the company.
Better team utilisation: on a rare occasion when one of the projects is temporarily on hold waiting for some further input.
Splitting time between several projects is beneficial when it does not involve a significant change in context.
Having a developer to work single-handedly on multiple software development projects negates the benefit of specialisation (there isn't any in the case), consistency and knowledge sharing.
It leaves just the advantage of time utilisation, however if contexts differ significantly and there is no considerable overlap between projects the overhead of switching will very likely exceed any time saved.
Context switching is a very interesting beast: contrary to its name implying a discreet change the process is always gradual. There are various degrees of having context information in one’s head: 10% context (shallow), 90% (deep). It takes less time to shallow-switch as opposed to fully-switch; however there is a direct correlation between the amount of context loaded (concentration on the task) and output quality.
It’s possible to fill your time entirely working on multiple distinct projects relying on shallow-switching (to reduce the lead time), but the output quality will inevitably suffer. At some point it’s not only “non-functional” aspects of quality (system security, usability, performance) that will degrade, but also functional (system failing to accomplish its job, functional failures).
By splitting the time between two projects, you can reduce the risk of delaying one project because of another.
Let's assume the estimate for both projects is 3 months each. By doing it serially, one after the other, you should be able to deliver the first project after 3 months, the second project 3 months later (i.e. after 6 months). But, as things go in software development, chances are that the first project encounters some problems so it takes 12 months instead. Or, even worse, goes into the "in use, but never quite finished" purgatory. The second project starts late or even never!
By splitting resources, you avoid this problem. If everything goes well with the second project, you are able to deliver it after 6 months, no matter how well the first project does.
The real life situations where working on multiple projects can be an advantage is in the case where the spec is unclear (every time) and the customer is often unavailable for clarification. In those cases you can just switch to the other project.
This will cause some task switching and should be avoided in a perfect world, but then again...
This is basically my professional life in a nutshell :-)