This article discusses an approach and toolset for testing Identity and Access Management and Identity and Access Governance solutions. The solution is comprised of the Account Manager 5 and the unreleased Rocket libraries. A virtual machine containing the solution is available upon request. Please contact me via LinkedIn to obtain a copy of the solution.
If you've ever used Identity and Access Management (IAM) or Identity and Access Governance (IAG) software, you've probably found yourself confronted by one of the following situations: 1) The software is a blank canvas on which to make a mess; 2) The software includes some sample data that seems to work just fine and snappy, but you're not quite sure how or why; or 3) The software is quickly pointed to a copy of QA or Production data and promptly blows up (or deletes everything). Perhaps consultation was purchased from a qualified vendor who knows what they are doing, and their experienced cadre of engineers works through proven processes to deliver you the solution you need. While some solutions are quicker to stand up than others, the spiderweb of IAM and IAG data lurking around your enterprise can quickly turn that solution into a sticky and confusing mess. You may or may know that already.
Wouldn't it be nice to know whether the solution is going to work, and can support your particular data, before hooking everything up? And, wouldn't it be nice to be able to run integration, performance and load tests without risking the dependent test or production directories and databases?
Trying to find out can be a lesson in futility. It's usually not in the vendor's interest to show you where the solution starts to fall apart. As for the data itself, demo data is usually too small and sanitary to draw out the cracks, and using your own data requires actually setting up and testing the system so it doesn't break anything. Then, there's the added challenge that, typically, production data is not always available or scrubbed for testing. When it is available, direct connections are not always the best or available choices, so importing flat file exports from the largest directories is usually the quickest place to start, albeit it's harder to get the overall spread of all applications right away. Therefore, it's hard to know where, when or how things will go wrong until you get connect to a system that has the size and variation of data that more closely approximates your organization.
The solution presented here is intended to push over the IAM and/or IAG software by shoveling in that representative data and, optionally, providing simulated managed endpoints that can approximate multiple provisioning and reconciliation targets, without taking any risk.
Note: I feel I have to make this point - Don't intermix fake and real data in your IAM or IAG system. Just tear it down when you're done.
Let's start with the basic entities used by all IAM and IAG software: People or Identities (depending on your vendor particulars), Applications or Services, Accounts, Permissions or Entitlements or Groups (which have variable meaning depending on the vendor), Organization Structure including managerial and location relationships, that black hole known as Roles, Business Descriptions or Business Activities, and the many workflow and policy options used to tape all of the entities together. The test tool uses a data generator within a DOM Worker to create and upload chunks of fake identity, account, and entitlement data to Account Manager 5 and Rocket APIs. The active DOM Worker may be used to create as many new applications as desired. When the first application is created, a master array of people and a randomized organization structure is created. Then, and for subsequent applications, accounts and permissions are created. After each application is generated, the DOM Worker uploads the raw data as Account Manager 5 DataType objects, and posts a queue request. A background thread manages requests and starts bulk loading the data into the Account Manager database.
The Account Manager 5 data structure, by design, compartmentalizes the entitlement and nesting structure. The Rocket library adds additional services and models to work with identity data from a community project perspective. The interface between the testing application and the IAM and IAG software can be a database connection with one of several canned queries that filter data based on Rocket projects and applications (see the following examples), or using the REST API, either of which allow N-number of people, applications, accounts, and permissions.
On a moderately configured VM, it takes about two minutes to load ten thousand people, one application, ten thousand accounts, seven hundred permissions, roughly sixty thousand entitlement assignments, and about a hundred thousand attribute values. In his example, because there are no roles, the Account Manager authorization engine doesn't spend any time rebuilding it's cache, but if it did, that would add a few more seconds. In comparison, it take leading IAM/G solutions with minimal tuning upwards of ninety to one hundred twenty minutes to load those ten thousand people, their accounts, and their permissions, which includes about one minute of database query time against the Account Manager 5 database.
Do you think your IAM or IAG solution can do better than two hours to onboard ten thousand people, and reconcile ten thousand accounts (one for each person) and all of their permissions from one application?
Almost every IAM and IAMG software treats people and account entity data as attributes, primarily because, most often, the systems of records and managed systems are directories. The Account Manager 5 schema supports multi-valued attributes on any factory object. Also, the data generator supports specifying random attribute values at the account level, and the queue is currently keyed to support up to ten custom attributes (this is easily extended) in addition to the named attributes currently being used.
People data is created by using the top twenty to thirty most common first and surnames in Europe and the Americas, including some with upper ASCII characters (not all names from Asia, Easter Europe or Africa are included yet). Also, a random gender is assigned to construct a gender-specific name combination. A birthdate plus a couple other niceties are also included. Fake mailing addresses are not included yet. Location data is currently only supported by specifying a custom attribute and supplying the location values, one of which will be randomly selected at the time of account creation.
Applications are created as DirectorGroupType objects within a Rocket project. Accounts and permissions are created relative to each Application. Accounts are composed of a pseudo-random name based on an alphanumeric prefix and numeric suffix, such as A123456. The generation process references the transitive people array, and if doesn't exist, will first generate the maximum number of people, and then create a random number of accounts up to the maximum person value. The people array is shuffled and then the random accounts are iteratively assigned to a person owner.
Permissions are created from a few pairs of random nonsense plus one of a small set of executive verbs; read, write, execute, etc. Business descriptions are assigned based on longer lists of published entitlement and policy lists from Windows, Linux, and OSX. When accounts are created, each permission is assigned to a random number of accounts. Keep in mind this is pseudo-random data, so the verb used in the permission name won't necessarily match the description.
After the first application is created, which includes the base set of people data, it is spooled to the Account Manager 5 server as persisted DataType instances, and a queue request is issued to a threaded queue monitor which bulk loads the data into the database. From the end user perspective, it's very short work to generate tens of thousands of new people and as many applications and accounts as desired.
While roles are a core feature of Account Manager 5, and can be used to create any kind of role hierarchy, the data generator does not include random role models. Rather, this was left out since the expectation is you would exercise role mining tools in your chosen IAM and IAG software.
Cleaning up the test data in the test tool is as easy as deleting the Rocket project. Due to the potentially deep structure in the normalized data, some orphan data will be left behind. Periodically, a cleanup routine runs that will purge orphan data.
Cleaning up test data from your IAM and IAMG software depends on the solution. If testing on a single virtual stack, it's recommended to take a snapshot before running any test and then reverting.
Once the test data is loaded into the Account Manager 5 database, it's available for use as a system of record and reconciliation point for one or more applications. The Rocket library includes several services and database views for representing identity service people, applications, accounts, and permissions. Therefore, the easiest integration point is to run a query using one of those views and specify the project name and, as needed, application name.
SELECT P.id, P.name, P.firstname,P.middlename,P.lastname,P.gender,ATM.value as manager,ATM2.value as email FROM identityservicepersons ISP INNER JOIN Persons P on P.id = ISP.personid LEFT JOIN Attribute ATM ON ATM.referencetype = 'PERSON' AND ATM.referenceid = P.id AND ATM.name = 'manager' LEFT JOIN Attribute ATM2 ON ATM2.referencetype = 'PERSON' AND ATM2.referenceid = P.id AND ATM2.name = 'email' WHERE projectname = 'Project Name'
SELECT A.id, A.name, AT.value as owner,string_agg(GAR.permissionname,',') as permission FROM identityserviceapplicationaccounts ISA INNER JOIN Accounts A ON A.id = ISA.accountid LEFT JOIN Attribute AT ON AT.referenceid = A.id AND AT.referencetype = 'ACCOUNT' AND AT.name = 'owner' LEFT JOIN groupAccountRights GAR ON GAR.accountId = A.id AND GAR.groupid = ISA.applicationid WHERE projectname = 'Project Name' AND applicationname = 'Application Name' GROUP BY A.id,A.name,AT.value
SELECT permissionname, ATT.value as businessdescription from identityServiceApplicationPermissions ISAP LEFT JOIN Attribute ATT ON ATT.referencetype = 'PERMISSION' AND ATT.referenceid = ISAP.permissionid AND ATT.name = 'businessDescription' WHERE ISAP.applicationName = 'Application Name'
In order to test provisioning operations, the REST APIs may be used to add, update, and delete person, account, and permission data as desired. Examples are not included here, but general documentation and Account Manager 5 source code is available on GitHub. Note: Neither Rocket source code or documentation is made available here.
Now comes the real test. Almost every IAM and IAG solution includes a database connector (eg: JDBC) for importing authoritative records and reconciling with target systems. Create new services/applications in your IAM and IAG solutions and provide one of the corresponding queries for people, accounts, or permissions. Note that the account database query includes a multivalue column for the permissions. The only thing that needs to be changed in the queries is the name of the Rocket project and the name of the Application. Within your IAM or IAG solution, update the attribute mapping accordingly.
I tried this approach on several leading IAM solutions both before and after applying recommended performance tuning steps. While most systems did a fair job of not dying right away, what did strike me was larger than expected amounts of temporary disk space used by some solutions when processing the data, as well as database and application server performance. Furthermore, role mining processes were hit and miss once the number of entitlements exceeded certain thresholds, which weren't very large. In some solutions, role mining continued to work as expected, while in others it became much less usable. In summary, then, this is the type of information that will help your IAM and IAG project succeed. Since success is largely determined by unique combinations of identity and access data, simulating that data and your applications may give you better visibility into how near or far from success you're going to be.
Raise your hand if your project planner types or copy-pastes every project milestone and phase into the project planning tool. If you have your hand in the air, I have a question: Why? Another question: How many times have project team members claimed that stakeholders were causing feature creep, or sales oversold capability?
Starting off a post-collegiate career principally in development, it was easy to be somewhat dismissive of the role that sales and business stakeholders played in the cultivation and evolution of a project. That naivety gave way to appreciation as I began to spend more time on pre-sales and roadmap-planning discussions. If you don't appreciate the sales department, get downsized a few times and see if your opinion changes. There's a whole domain of information related to the sales and roadmap-planning discussions that rarely finds its way into the project plans. That information is usually kept separate in a Customer Relationship Management (CRM) system or roadmap planning tool, and is used for lead generation, budget and commission tracking, etc. Some information from these systems, such as project milestones, schedules, roles, and estimates are shared, usually by printing or emailing a copy and then copying those values into another planning tool. Those two systems include the milestones and deliverables that sales is tracking with the customer from an account management perspective, and the roadmap that business leaders and stakeholders are using to guide and track progress against long term objectives. These are the project milestones, and they should be defined at a source. Consider the "Roadmap" diagram. At a high level, it appears too simple to be of much use. Nonetheless, these are the cornerstones of a project plan. It's what the customer and business were sold. Depending on the type of business and engagement, sales may influence the roadmap by defining customer feature requests, or in the case of vendors, by contributing the stakes. The corporate roadmap defines the goals for the next year or years, with projected budgets. Project teams may not see all of this information now (such as the budget), but that does not mean the information cannot still be directly related to project plans.
Time and money are the inputs into most project management models, such as the classic triangle or diamond. Those pesky customers and business stakeholders like to think in those abstract concepts of time and money. Why should a project plan factor in how much time the whole affair takes if its activities do not represent the whole, or the time and money components include non-project related work? Believe it or not, time and money are not infinite reserves, and even if an organization has a fixed budget with a use-it-or-lose it guideline, keeping a project plan disconnected from the roadmap and sales information results in feature creep and compressed schedules. If sales are compensated by net revenue, and business leaders are compensated by achieving those goals on time, on budget, or sometimes both, then it behooves the entire team to collaborate, which may seem counterintuitive when project teams usually don't want or need to consider those factors. Doing so helps everyone pin project plans against communicated milestones and schedules, versus a copy-pasted version, and then trying to squeeze the plan into those constraints.
Does this sound familiar: How long will it take you to do some work? It has to be done by this date, and it can't cost more than that amount, and it has to include these features. Give a project team such boundaries and they'll add fifty stakes (called assumptions) and a hundred reasons (called risks) to explain the snake-oil recipe needed to make this happen. Cue the random comparison to a fantasy or battle. Everyone laughs. Sales and business leaders are not amused.
Eventually, everyone gets down to brass tacks and the business and technical leaders are tasked with coming up with a high level plan. What will it take to get to the goal? More hardware? Virtual environments won't run without available resources. And IT has to work some networking magic. Add in some gap analysis and requirements gathering. Don't forget the design work. This is going to take a whole lot of design work. The architecture team will get back in a couple weeks to define how long the design will take. At some point in the overstuffed version of the plan, someone proposes: Can we do all this in parallel? Sure thing! Dependency analysis is needed. Oh, and by the way, the project team is Agile, except IT hasn't figured out how to iteratively upgrade the hardware for the virtual infrastructure, so the project methodology will be Agile-fall with automated testing all around. When the kickoff meeting ends, there's an initial push to get that first plan back, where it languishes for a while until, one day, the time comes to execute it.
And that plan, more likely than not, is a complete fantasy. The dependencies become unreasonable or are unattainable, and the goal everyone is working towards looks nothing like the actual goal. Sure, it may be written down the same way, but the journey being taken will lead to a different destination. Somebody, somewhere, is going to pull the emergency break and the project plan then either has to be rewritten, or all the hard misdirected work becomes shelfware. The reason? Because the goal everyone was running to was "The One Ring", taken there by the myriad activities that didn't correlate back to the original requirements. Even the twisted fantasy version of the project plan the team wound up running with was never right because the one ring should have started at Bag End anyway. However, the message back up to the stakeholders and/or customer gets massaged in such a way that everything looks fine on paper.
In a reasonably sized organization, projects with multiple teams will have mixed project methodologies, and both hard and soft dependencies that dictate when activities may run in parallel, and when they can't. However the project is run, and it shouldn't matter how so long as the method is efficient and effective, then pinning the project directly to the stakes and goals defined by the leadership team makes it apparent whether and how the project is falling off track. Likewise, separating efforts by methodology, but keeping the dependencies intact, allows teams to operate independently and more efficiently, while also tracking progress of those dependencies. How are these cross-project dependencies tracked in practice? Either by adding unlinked records into the project plan, tracking the cross-methodology work items in one plan, or writing two separate plans. Schedules, which define the time frames in which work needs to take place, may be attached independently to the projects and project phases. Therefore, the impact of something like the late delivery of a hardware purchase is an actionable event to other project teams as well as stakeholders, all the way up to the customers and business leaders. While arguments may be made that such details are not always pertinent, the influence of those details are pertinent. If that warning is not acknowledged, it gets swept under the rug and it falls on the dependent projects to make up the difference. This leads to conversations that begin with: "Why are we behind schedule?" which translates into "Why are you behind schedule?", and which really means, "My milestones aren't being reached, and why am I only finding out about this now?" At this point, the person in the hot seat will either shift blame, or refer back to the various risk and assumption communications; what's commonly referred to as CYA mode. However, the issue is more insidious than a late dependency wrecking a project further down the line. A contributing factor is what type of information is being captured by plans in the first place, and what an organization is even willing to track.
This situation can be avoided by making sure the unmanaged message, the unvarnished truth, is made clear straight up the stakeholders and then pinned there so the issue can be prioritized and dealt with. Sending an email does not count, nor does making a phone call. That ugly status must find its way back into the same place the milestone was initially set. If the reaction is to manage the message until the issue goes away, because the board or executives won't react well (or whatever the reason), then the remainder of the plan is a fantasy. If you're in the mood to read fantasy, I highly suggest this one.
Here's an exercise: Add up all of the time spent planning to plan the project plan, including all meetings, conference calls, roadmap work, analysis, and any other work needed to be complete before actually writing the project plan. Is all of that time included in the project plan? Probably not, because, as the typical response goes, the plan is for pending work, while those meetings were just pre-planning work. Well, I have a word for that, and that word is - you thought I was going to write waste, didn't you? No, it's overhead. It's work that needed to be done to get the project started. This includes all of the sales and accounting related discussions, all of the executive and board meetings, the phone calls, the emails, the proofs of concept, and everything else. Why isn't this being tracked? "They are never going to record their task hours," is one response I've heard. And, "We don't track capex unrelated to actual project work." I've heard a lot of reasons why not. And I don't agree with any of them. I think the time spent in the meeting between the architects and CTO needs to be tracked, the time the PM and stakeholders spent fleshing out business requirements needs to be tracked, and the time spent getting all of these materials ready to start a project plan needs to be tracked, and all of the time spent in meetings needs to be tracked. Why? Because all of those represent time and money invested in the project, ostensibly for a good reason. That is also time and money spent from a budget, either by cannibalizing another project, or from that general slush fund called payroll. If there is a good reason to do that work, then it's worth tracking as overhead. Otherwise, it's waste.
Overhead and waste can be expressed in terms of a project plan by identifying the module (or assembly) that a project produces, associated with a stake and goal, and by identifying task artifacts and dependencies. A task that does not satisfy a dependency, or does not produce an artifact, is waste. A project that is not associated with a stake or goal, or does not produce a module that satisfies a deliverable or dependency is also waste. There seems to be an aversion to tracking time and money spent prior to tasks articulated in a project plan, even though time and money are the key inputs into the plan. If those values are not tracked, then it's less likely that the project plan, or even the roadmap, will be more than bad fiction if the first action is to ignore the sometimes sizable effort required to create the plans needed to achieve the specified goals.
Finished adding up all the time spent getting read to write the project plan? Good. Now, make a quick little project plan out of those activities and lump them into two groups: Group A is everything used to create the project plan, and Group B is everything else. Group A is overhead, and Group B is waste.
One more exercise you can practice in your next meeting. Count the number of people in the room and on the conference call, and multiple that number by the average hourly rate for your industry. Be sure to include taxes and benefits. For example, fifty USD per hour. If there are ten people present for a one hour meeting, that's five-hundred dollars of money, and ten person hours. Then, that twenty minute follow-up discussion at the wipe board with half the attendees, is another eighty dollars and hour and forty minutes consumed. The ten and twenty minute ad-hoc discussions, which often times are very valuable, still add up over time and contribute to either overhead or waste. The differentiating factor is whether or not it produced something that is ultimately used to reach the goal.
Not tracking the overhead cannibalizes the resources from the project because the teams wind up working towards the same goal with less time and money than budgeted. And the gaps between actual time and actual cost lead to all sorts of problems later on: Condensed schedules, project rework, and budget shortages, and schedule slips.
The efficiency of a project plan can be improved by directly connecting the goals with roadmap milestones, capturing preparation work as overhead, and then by defining the work product at a task level to classify waste.
Here's an exercise for tech workers: What process must you (or do you) take to schedule, approve, plan, design, build, test, and release the following: A text change to a compiled resource. How many people are involved? How much time would it take? Go one, add it all up. I'll wait. All done? I like this exercise because the answers are both defensible and ridiculous. There's a reason for the people and process involved, and this one type of change should engage most if not all of the people and teams. One of the first times I did this, the answer was astounding: Eight people and twenty four work hours. As a consultant, I've had the opportunity to ask this question to many different organizations, and, for better or worse, it didn't get much better. So, the next question is: Why? Doesn't this seem wasteful?
It does to me. I grew so frustrated with rewriting the same project schedules to accommodate methodology nuances that I tried to figure out a better way. Rocket is my attempt at finding out where the waste is in the process (E.G.: via Theory of Constraints). This article introduces the Rocket platform. By way of introduction, here's a concept drawing of the Rocket entity community: Assets, Business, Processes, and Projects. And, let's get one item out of the way: Rocket represents complicated project relationships and dependencies across multiple organization segments; it is not intended to be a variation of Microsoft Project, or mimic online project management tools. There are legions of people and truckloads of money dedicated to making those products work, and they do a good job. Then again, if you find yourself wondering if you're just wasting your time, well, wouldn't it be nice to know where it's being wasted?
Another exercise for everyone currently working on project-oriented work: Where are the business requirements written down? And the technical requirements? And the use cases? Architectural drawings? All on the wiki, some say? Well, bully for those who do, but I suspect a fair number exist in separate documents. Do they exist relative to any project plan? Probably not. Now, if those items can be considered digital assets to the project plan, how was the plan created from them?
Thinking of requirements as an asset, as something that isn't only useful for reference, but something that can directly feed and drive a project, can increase the practical usefulness of the plan. Besides requirements, what other assets, digital or otherwise, are available? Time, money, people, documentation, prior design work, support tickets, bugs - just about anything you'd need to start. You may not actually get all or any of those things, but it's a place to start. There's a fount of information lying around, usually in a format that doesn't really help. What if that information was put to work? While there may be preference to do designs and proof of concept work without first taking stock of what's presently available, doing so adds risk of duplicating work or embarking on an effort that could never work within current constraints. This is a pretty big challenge because many people want to create and contribute, sometimes to a fault, and sometimes at the expense of ignoring what already exists. Furthermore, understanding the current assets helps form the foundation and boundaries. Maybe the answer is to throw it all out and start over, but if the first action taken is to ignore what previously transpired, then, as goes the aphorism, get ready to repeat the same mistakes. Even though it's good to think outside the box, there still needs to be some semblance of a box to think outside of, and identifying the assets helps form that box. Most of these materials will exist scattered around: File shares and content management systems contain documents and drawings, HR and Identity Management systems contain people, existing project plans include upcoming schedules, etc.
These types of assets, including people, data and their entitlements, can be imported and modified in bulk, and in the case of files, maintain a foreign key to the source.
Organizations have requirements to articulate what activities they want done. When something is desired, it's written down in a variety of formats. Unfortunately, the business and customer use cases and requirements often times go missing or are usurped by technical requirements that mow-over what the business originally wanted. Let the requirements be captured early, and let them persist relative to the project plan. Similarly, large organizations draw on technical leaders to pen new designs while accommodating existing functionality. Let those blueprints hang, virtually, along side the requirements. These designs do not need to be complete (design up-front), but if the relationship is separated from the plan, or created as its own plan, then it's discrete from the implementation. Also, there are budgets of available time and money to consider, and the allocation of how much time and money may be spent within a window of time. Let those values be defined and referenced, whether they are visible or not, relative to any projects.
When the organizations methodology is formulated, and the requirements, use cases, and blueprints can be expressed against budgets and schedules, then a project plan can more easily be the representative tool it's supposed to be of what an organization wants to do, how long it will take, and how much it will cost. And, the relationship of the plan against the business drivers makes apparent what is wasteful in attempting to achieve a goal.
Organizations want or need work to be done in a particular way. Project and program managers define and execute project planning methodologies that correlate work activities against corporate and project requirements. While there are a number of project management methodologies, no one way accommodates every organization. For example, a waterfall project at Company A looks very different than a waterfall project at Company B, or an Agile Sprint at Company C smells nothing like an Agile Sprint at Company D. Because of myriad nuances affecting the process at each organization, and even between divisions and teams within that organization, it's important to be able to articulate the required methodology: What processes need to be followed, what are the time and cost constraints, and what are the goals and requirements common to every project following this process? At some point, a project plan may need to reconcile work performed across competing methodologies, and this is more readily accomplished when the methodologies are codified.
Organizations use project plans to introspect roadmaps, release schedules, allocate resources, and track work details. These plans exemplify the strategies and methodologies used to execute the project (I.E.: program management methodology), which steps are followed (I.E.: lifecycle phases), which artifacts are created, and how much is this whole thing going to cost, anyway? Functionally, lifecycles aggregate projects and related goals and budgets, and projects aggregate stages (aka phases) of work for a specific schedule. Projects accept models, requirements, dependencies, artifacts, and modules, and produce one or more modules or artifacts. Each project stage is a procedure of work according to the methodology, accepting or producing modules and artifacts. Work is a set of resources and tasks used to produce artifacts. Tasks, or the specific activities, represent one or more requirements that operate on other work, data, and/or notes to create artifacts.
Here's a fable for those familiar with Agile. A pig and a chicken are walking down the road. The chicken says, "Hey pig, let's open a restaurant." The pig says, "What would we call it?" The chicken says, "Ham'N'Eggs." The pig thinks for a bit and then says, "No thanks, I'd be committed but you'd only be involved."
Let's consider this fable for a moment. This fable is commonly used to describe the two types of project members on an agile team. A fable tells a short morality story. The moral of this story is the pig doesn't want to do it. Why is that? First, organizations and businesses, in almost every case, are not democracies. They are most likely an oligarchy. Efforts to foster communication and collaboration tend to be a passive-aggressive delegation of responsibility. In the Agile/fable sense, the chicken delegates the responsibility to the pig, and, at least by my observation, unaccountable for the outcome. Iterative development using scrum and TDD can be employed to great success, and it fosters collaboration and team-building. But even then, at its best, it leaves the chickens unaccountable for their influences, and those influences contributed to waste.
In an Agile environment, with chickens and pigs (who, according to the fable, don't want to be there), the resentment can be tangible. The overt or passive-aggressive response seems to be akin to the pig waiting for the chicken to turn its back and saying, "And, we'll serve Hot Wings."
In other words, it's important to acknowledge the power structure in which the planning takes place, because that heavily influences how certain activities should take place. Ultimately, this affects how teams collaborate, and what types of communities can form within these environments. The following is an idyllic project planning exercise: Show up, have all the requirements and resources available in an easy-to-consume format, have the preferred methodology and all of the stakeholders' various nuances in place, and then fill in the blanks to turn those requirements into a finished work product. The team collaborates to define functional requirements and test cases, and then is able to get right to work. Somehow, though, far too much time gets spent mincing through requirements in one document, and let's not forget the requirements in these other two documents, and let's just table these other requirements to get the detailed planning done, and, don't forget, let's have a meeting about everything and a follow-up meeting on that meeting. Most people acknowledge these shortcomings of the planning process, and the solutions lean towards fostering better intra-team and democratized communication, which is a circular, if not impotent, distraction from solving the real issue: Stop wasting time and resources.
The Rocket Community is the entitled access to some or all assets, some or all business elements, the program management process, and the capability to quickly integrate these together to create a plan. This isn't a tool to solve a people problem; It's a tool to help clarify where the constraints are happening.
I tried applying some common sense and a few management paradigms to program management in an effort to correct what I thought of as wasteful behaviors. Rocket was the result. Up next, we'll take a closer look at some of the features.