Please login or join to subscribe to this thread
I see running this as either a program, or what we used to refer to as an "omni-bus" project. I can see huge efficiencies running this way as opposed to separate "stovepipe" projects.
I agree with Steve. You could manage each instrument as a different project, the common user interface is another project, and they are all toghether into one program, which can be summarized for this pupose as a group of interlated projects with take advantage of shared resources and reach economies of scale.
Thanks for the responses. That is kind how I have laid it out already where each instrument is different and the common pieces are their own project. But now I'm getting stuck with the Project Management Plan where many sections will be the same. It seems like a big time suck to make all separate Project Management Plans for each instrument. Does a Program help with this sort of thing?
Although they types of activities might be common across projects, that does not mean they are the same activity, or they necessarily have the same timing, especially when you need to deal with external vendors. What you are seeing is that you could essentially create a WBS template that can be used in the development of multiple instruments without recreating one from scratch each time.
Often situations like you describe are managed as a program. The development of each piece of hardware has an independent team working to their own schedule for detailed level deliverables. The plans will still have common elements because they are similar types of hardware. In aerospace programs, we maintain the same WBS for decades. The *structure* of the WBS is the same, even though the detailed level SOW that is organized in that organizational structure changes.
Because you have a common interface, you will have some major milestones that should probably be combined such as PDR, CDR, any major gated reviews, significant integration milestones for your UI, etc. You may have a unique PDR (etc.) for each instrument as well because you are working with separate vendor, but at the program level you have another one as a major integration milestone.
That's where it looks more like a program than a large project. Many activities on sub-teams can be managed independently, but the major interface points must be combined for all the projects to integrate together, with planed coordination points because in some select instances, the work of one project team is dependent on the work of the others.
In the aerospace projects I work, we will frequently have multiple specialty technology teams developing electronic "black boxes", and an integration team (my role) to ensure coordination between teams aligned with a single program level schedule.
I hope that helps.
So, to clarify, you are saying each instrument or project should have its own unique WBS, but there may be milestones or integration points that are scheduled properly in order to coordinate the projects. That makes a lot of sense. The struggle here is that we are a small, family-owned company that sells industrial equipment internationally . To get products designed and developed more efficiently we have decided to go the Project Management route. I'm just trying to wrap my head around all the documentation/planning that is needed for this. I'd like to make this as efficient as possible. Thank you for your help. #strategyiskey
A WBS is the structure, like a filing system broken down by categories, not the work itself. PMI often confuses it with the narrative of the work statement, but it predates PMI by many decades.
The detailed level work may be different but you can organize it the same way. In an electronics program such as yours, the WBS might be organized as follows:
WBS Level 1: Instrumentation program
WBS Level 2.0: Program integration
WBS Level 2.1: User Interface
WBS Level 2.2: Instrument 1
WBS Level 2.3: Instrument 2
IEEE has a very comprehensive example if I remember correctly.
With each instrument, you can develop a common organization scheme. Usually the zero level (e.g. 2.1.0) is integration. From there you break it down in to a product level decomposition, often organized by technology/skills.
Chassis, optics, controls, wiring, circuit boards, etc. will get their own branch of the tree, but they are organized the same way such as Chassis is always 1, Optics always 2, etc. By creating a super-set type organization, you have an intelligent numbering system where each digit tells you the category of work. If you have an instrument that doesn't need them all, like there are no optics, then you just leave that blank, but you preserve the numbering system itself, even if some folders in the filing system don't contain any work.
When you have the same task required on multiple instruments, you can just copy it into the right branch for each instrument. The activity for each instrument is unique unless it's an integration activity, so to be able to track separate tasks, you list it each time it's performed, even if the description is the same.
By having the same structure, it's easier to see if you included all the right tasks for each instrument. By being able to copy it, you save time building your work statement. By having each task discretely called out for each instrument, it is far easier to schedule and track.
This product level WBS and the corresponding part numbering configuration management go back to Henry Ford. There are other ways to do it, but that style of product oriented WBS organization is extremely common and highly effective.
Please login or join to reply