There was a wonderfully accurate commercial for EDS several years ago that drew an analogy between IT infrastructure and development projects and the concept of building a plane while it's in flight. That comparison should be very easy to grasp for a lay person, even though they may not fully appreciate exactly how spot-on it really is.
If we compare projects in other industries to IT, we find that most of them do not have to contend with active use of what they are building while they are building it. I'm not talking about renovations or general maintenance; I'm talking about the plethora of IT projects that wind up in quasi-production by the halfway point of their construction.
This might be because data is flowing from various sources that were opaque before, offering a tantalizing buffet for the folks who need to analyze and react to that data. Of course, the proper interfaces to distribute that data haven't been built yet, but someone finds out that a database is being populated with the raw data and very understandably wants to have an early look at it to further their own projects and goals. Even if there was a plan for early user acceptance testing, there are usually folks who want in much earlier than planned.
Or it might be a new virtualization infrastructure that has been freshly built out but not fully tested, and migration plans from the prior infrastructure are still underway. A group working on mission-critical tasks asks for early access to run their heavy validation workloads to potentially shave hours off their testing times while the rest of the less-critical infrastructure is migrated.
Taking one for the team
Properly managing requests like this while still in full-on build mode is absolutely critical to the overall success of the project, and shouldn't be summarily discounted because the project is not 100 percent complete. Naturally, everyone wants their projects to be first in line for any new IT or development resource, and they can provide numerous reasons why they deserve to be. Many times, those justifications are not terribly difficult to deliver on early, and may actually help the overall effort even though they might seem to pull some resources from the project itself.
It's extremely important when granting early access requests that the requestor understand that there are no guarantees. If data is requested, it may be incomplete or hastily formatted. If infrastucture access is requested, it may not be completely stable, and there are very real risks involved. Usually, the folks asking for this special dispensation are more than happy to agree to these terms if it gets them what they need.
The key in acquiescing and delivering on these requests is to do so in a temporary manner that is understood to be replaced later -- and the most important part of that is actually replacing these mechanisms later. The inertia presented by hastily constructed access can be difficult to overcome if left for too long, so follow-through is crucial. Document the process, and even consider flagging the early access methods as bugs or issues to make sure they get fully removed.
Turning the tables
And don't overlook the potential benefits to IT here. Many times these eager beta testers can ferret out (hopefully minor) design flaws or bugs that would have otherwise fallen through the cracks until much later. Depending on the details and severity of the uncovered issues, identifying them at such an early stage can result in significant time and cost savings versus having to backtrack later on.
Try as we might to create full-coverage tests and validations, some aspects of a new system only become visible in a real-world scenario. If it's appropriate to allow some real-world access early, it could ultimately benefit everyone involved. Also, if unforeseen, unrelated problems crop up down the line, pushing back a deadline or delivery date might be easier to handle than if those stakeholders had been kept waiting until everything was perfect.
Providing early access to data could be as simple as dumping out raw CSV exports every day. On the infrastructure side, it might entail carving out some space early for a few VMs. You might find out early that some of the data doesn't align with expectations or that a critical data source is not as bug-free as previously thought. You might find that there's a corner-case performance issue on a virtualization farm due to a minor misconfiguration on an Ethernet switch that would have caused big problems later on.
As long as it doesn't jeopardize the overall project and can be done relatively easily, there may be no harm in complying with some requests. Of course, this isn't a hard and fast rule, so some discretion is advised. Depending on the personalities and realities of the request itself, allowing early access could blow up in everyone's face.
In the course of completing big projects with significant stakeholders, we try to do everything right the first time and deliver an impeccable product right out of the gate. Achieving that goal takes time, perseverance, and focus -- elements that can be strained when granting early access. However, these things are rarely black and white, and sometimes playing the nice guy is the right move.