Trying to get non-responsive members of the team be more schedule sensitive

We know this problem, it happens all the time. You have different members of the team, some more disciplined and some less disciplined. Actually discipline is the wrong word. When you have creative members of the team, or team members who are attached to multiple projects, then there can be problems with respect to scheduling of their deliverables. In the case of team members such as User Interface Designers or Visual Experts, or Visual Designers, they typically do not move to the same beat as that of the rest of the project teams, such as Engineers or Testing Engineers.
This can be problematic for the rest of the team, since schedules are interlinked to each other. For example, the User Interface Designer would prepare design specifications that are used by the team members to discuss and finalize the feature workflow and the technical architecture. These are then developed and passed onto the testing team which does the testing and then releases the feature. However, if the initial design does not come in time, then the rest of the schedule will get impacted.
One of the problems that I have experienced with User Designers or similar creative people is that they do not work in pieces; they would like to look at the overall workflow for the product and then release a completed design. But the team does not work like this, it would like workflow designs feature by feature, so that the work can be done feature by feature (and it makes logical sense).
Another option that could have been postulated is that the Workflow Designer could have a period of 2-3 months before the start of the cycle, so that the Designer gets enough time to make the design. This seems logical, but there are problems in this. The Workflow Designer does not work entirely on his / her own, but needs to work with the Product Manager and the team members (the team members  are involved so that the team could figure out the technical cost of doing the Workflow designs; some of these workflows may take more time and effort than other workflows and the contribution of the technical team in figuring out these is critical. This process can be iterative).
So how do you work out trying to get such more creative members as part of the process?
- First and foremost, it is necessary to ensure that you do not make the assumption that these resources understand the critical nature of meeting their schedule deliveries. It would be needed to spend much more time with these people and form a detailed plan for deliveries, doing this discussion multiple times till an understanding has been formed.
- In my experience, it was also necessary to have 2 dates in the schedule with a few dates gap between the 2 dates. It was necessary to push the delivery to happen for the first date, but there was also the understanding that the delivery happening on the 2nd date would also work fine without threatening the schedule.
- It was also realized that there was the need for a regular reminder along with checking about state of progress and updating the rest of the team on such progress. So, the Project Manager had setup a weekly meeting with the workflow designer to discuss the state of progress and the deliverable, and figure out alternatives if there was a delay.

Working with people who are not so responsive as developers or testers ..

It can really test the patience of a team when they work with people who do not seem to follow the same guidelines, processes and schedules as the rest of the team does. It seems a bit odd though. The schedule is the most important item of a software development project, with a lot of effort going towards determining whether the team is following the schedule or not, and if there are any slippages from the schedule, it can imperil the success of a project. If there are slippages of the schedule, then it would take a lot of effort from the project manager and other managers and senior members of the team to get the project back on track. In such a case, it seems strange that there can be members of the extended team who are not so committed to the schedule (actually, it is not right to say that they are not committed to the project, it is just that it can be a challenge to get them to follow the details of the schedule).
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.