Welcome to the Smartsheet Forum Archives
The posts in this forum are no longer monitored for accuracy and their content may no longer be current. If there's a discussion here that interests you and you'd like to find (or create) a more current version, please Visit the Current Forums.
Multiple project sheet schedules or only one?
OK Community, help me out here.
I keep going back and forth (and forth and back) on this issue.
I think the answer is "it depends" but I'm looking for feedback on more "what is depends on" sort of things so I can be confident I've chosen the right method for the current projects.
Here's the situtation:
I have multiple projects that are using the same team, often with the same goals, and with the same company.
For Customer 1, we have four projects.
Project A: Integrate gizmo into widget for plant A.
Project B: Integrate gizmo into widget for plant B.
Project C: Integrate gizmo into widget for plant C.
Project 
Do something else for plant D.
Start / end dates different (or the same).
Stakeholders overlap (management or worker teams are either mixed or completely different).
If I put all four projects in a single schedule sheet vs splitting out into four sheets, what do I get or lose?
Advantages:
I can easily reconcile timing issues. That is I discover there is a problem with May for one or more projects, I can filter and
investigate easily in one sheet.
Sharing to the stakeholders is easier with one sheet. Even though some users seem OK with three Excel spreadsheets with 10 tabs each, they balk at 5 Smartsheets (is that common term?). There is a disad to this below.
Synergies, opportunities, and risks are more obvious (to me) when looking at the schedules in one view. I could use a dashboard for this, but I want the dashboard to be as clean and compact as possible.
Disadvantages:
If there are multiple sheets, then the resource issues for a particular project are clearer in the Resource View - instead of one line for “Customer 1 projects” I can see on Project B has the issue.
I lose the critical path of each project. Project A and Project B may share engineers or PM’s or computer resources but if Project A is delayed, Project B can still finish, even if originally scheduled to end later. There’ a reason it is called “the critical path” and losing that tool for a complex project seems like the biggest drag back.
If there are some stakeholders that should only see their project, this is extra work when only one sheet is used.
If there are multiple PM’s (on either side), sheet level alerts become harder to implement. They can be done, but it takes a bit more time.
And there’s no way to prevent the PM on Project A from doing something to the schedule on Project B.
I’m going to keep thinking about this and expanding on the questions to ask to make sure the best solution is chosen.
Unfortunately, too many knives in the air to focus on the topic completely.
While my brain percolates, any and all comments are welcome.
Craig
Comments
-
Craig,
First of all, kudos to you for being willing to take advice from others. There is an old proverb that says, "Plans fail for lack of counsel, but with many advisers they succeed."
Based on what you've shared, the "What it depends on" would seem to be how frequently you are having to do those things you list as a disadvantage. And if having to do the negative tasks more frequently outweigh the positives. And/Or if the negative tasks have more risk if they occur vs the positives.
For example, if you are having to frequently pull out a single project from the sheet that contains ALL projects, then you may want to move each project to a single sheet.
Based on the comment you made above about "...“the critical path” and losing that tool for a complex project seems like the biggest drag back,".....that seems to be your biggest priority or advantage. As such, I would suggest the single project view.
Is that item the biggest priority to you and the stakeholders?
Tim
-
I had a similar thing at my company - two different channels of distribution, siloed management, collisions of resource requirements. In the end, I managed the projects separately, but have rolled them up to an executive summary sheet that I have to curate. A mix of critical tasks and high-level timelines to those points of execution.
First thought was to co-track items with links and create reports, but reports would show those linked items twice and I would have to manually de-dupe.
The way I achieved the high-level report was to make sure I was indenting sub-tasks that led to critical milestones and linking the top-level task to the executive sheet. So far, I can put it on one 11x17 - which is frankly all anyone really wants to stomach. It takes some time, but ultimately is a great dashboarding tool for project health.
Just some ideas.
-
Tim and Ben,
Thanks for the feedback.
Tim -
And the kudos. I actively seek to learn from others.
I must have mis-explained the issue with the critical path, because my conclusion was opposite yours. I want to see how to shorten Project A and that is by investigating and changing the critical path on A, not on the collection of projects.
Your points about frequency really nail it. I'm trying to capture that as I build this monster consolidated project. I keep this comic in mind and use to have it on my wall when I had an office:
Ben -
Sounds similar. I have the dashboard built, it collapses to the project overview, captures flagged issues (with a link to a report if there are any), and shows milestones when expanded. I always try to keep the dashboard smaall enough to display on the screen. With lots of colors.
For the manual de-duping issue, I create a column in one (or more) of the sheets to tell the report not to display it.
Thanks again to both of you. You've helped.
Craig
-
I took Ben's approach for my programmes which involve multiple project sheets. This gives me a summary report that prints onto a single A4 page (so execs' PAs can print out for them) and if they log into the system they can click a project title on the summary sheet to go to the detailed plan.
-
It's a pain to set up the summary sheets, but not too bad to administer if things don't change much.
-
Thanks Chris.
I'm nearly convinced that separate projects is the way to go.
I may even investigate how long it takes to create a single sheet that is linked to all of the separate projects. Linking large data sets is time consuming, but may be worth it.
I'm collecting data on every time I say "It would be better the other way" to see where the cost benefit analysis lies.
Thanks for all the input!
Craig
-
Craig, I have similar challenges facing our organisation with multiple projects. I've found that not only do I break the projects up into separate projects, but I've started to break the projects up into separate sub-projects (obviously where there are clear boundaries that allow you to do so). This then allows critical paths for the different sub-projects to be seen. I use cell-linking to pull in milestones from the other schedules so that dependencies can be set off the milestones appropriately so that everything hangs together. It might not be the most elegant solution, but it is working well.
There is also an overview schedule sheet that I run which is purely cell-links to other sub-project schedules. I also use reports quite liberally to generate specific views of the schedule quickly and easily.
The logic is that it is quick and easy to mentally grasp smaller schedules, but a massive schedule with several hundreds of activities becomes cumbersome to the point of being a burden, not an aid. After all the schedule is supposed to help the project management, not become an additional chore.
Feedback from my colleagues is that they like how it is broken up into smaller schedules, as it also helps them understand it better.
-
Peter,
Thank you for that!
Odd that is it has taken me so long to come to this conclusion.
When I program, I always preach "break it up into smaller chunks to aid testing"
Great best practices from all!
Craig
-
Update:
The overal project I was supporting has 7 different sub-projects - all linked by the coordinator, manager, graphics and marketing work, and the vendor.
However, lots of the work done by unique (in most cases) persons.
All of these are also tied to an ongoing project that is nearly complete and some common tasks.
We had started out with a single sheet for the overall schedule. That really helped when looking for resource issues, but for the reasons above turned out to also be a negative.
We moved the common tasks and the major milestones of the nearly-complete project to its own schedule and then each of the 7 other projects have the common milestones linked at the top of their schedule.
If there is a slip in the common or nearly-complete project (and there are), then I get 7 emails showing what has changed in each and how they are impacted.
Because I set out to make any project contingencies or planned delays / padding obvious from these emails, I can make planning decisions from the email report before I even get back to the sheet itself.
An unexpected but welcome benefit to the Alert emails and splitting the projects.
Craig
-
Hello
Is anyone willing to share screen shots.....or copies of their sheets, because what you are all doing is something i need to do with my sheets and i am not succeeding to the VP's standards.
I understand the cell linking, reports etc...i just need a little "inspiration".
If anyone can help that would be great.
Thanks
Louise
-
Louise,
Send me your email address and I'll see what I can find that is not proprietary to my customers.
jcwill23@gmail.com
I'm away from my desk until tomorrow, but will see what I can dig up.
Craig
-
Craig,
I'm in a similar situation to Louise. Would it be possible to share any of those screenshots with me? Would really appreciate anything you can share to get me started. Thanks very much. My email nathan.hyslop@azapak.com.au
Nathan.
-
Yes.
Craig
-
Craig would you mind sharing those with me as well. eloyalcantar@gmail.com
thanks!
-
Hello Craig,
It seems your post is popular! So if you don't mind sharing that with me as well:
camilo_pereira@yahoo.com
Thanks!
