Latest Contributions by Bud

Here are my updated questions: Who Who is making this request (what level of management)? Do you have senior management buy-in/approval? Are there any conflicts? Has anyone else already done this or is planning to do it? Who will provide the data? Who will be on the project team? Who will maintain the product and how often? What What do you want? Can you show us? Can you mockup an example in Excel or Illustrator, etc.? Give them what they need, this may not what they are asking for. What does "Done" look like? How will we know the work is completed to satisfaction? Consider getting a written answer to those questions to avoid wandering scope. What filetype/platform?  Do you need a table, chart, print map, web map, or something else? What are the product dimensions/specs? When When will we have what we need to proceed? Where does it sit in our list of priorities? When do you need it by? Where Where is the data? Do the team members have access? Will the final product be sensitive, internal, or public? Who needs access? Where will the final product live and for how long? Why Why are we doing this? Why now? What happens if you don’t get it in time? What are you going to do with the final product? Does the product provide a good way to measure performance—such as measuring a team against a desired outcome? How How are we going to do the work? What's the plan? Cleaning Does the data exist? How reliable is it? Was the data entered correctly and is it easily query-able? How much data cleaning is required? How long will it take? Who will clean the data? Will we clean the source data or a copy of the data? How accurate do you need the analysis result/data to be? For example, if we were to estimate that the data is 95% accurate, is that sufficient? Notes from a colleague:  #4 and 7 both sort of cover this but it's critical to ask if the data exists, how reliable is it? In Work Order Management software terms, failure analysis is pretty popular right now. Everyone wants to say they can help predict future failures. But the number of organizations that aren't even capturing failure data or are capturing it in free form fields (like long descriptions) where the same problem can be reported dozens of different ways by different people makes it really difficult. Even when the data is structured, such as using problem/cause/remedy, most companies don't have all the possible options. Things constantly end up in the wrong bucket because the fields are required but the correct option doesn't exist in the eyes of the technician. Even if you have the data, you can't necessarily get anything valuable out of it. Most analysis requests come from managers/executives that don't really understand the problem trying to be solved. You need the people that are capturing the data to explain how they capture it and the challenges they have with capturing it reliably. #5 the first question "why are we doing this" and the follow up question (in my eyes, don't see it here) is "what are we going to do with this" is extremely critical to me. Managers love KPIs because it gives a way to measure the team against some desired outcome. For example, if you want to focus on quality, you will set objectives for number of defects. If you want to focus on customer service, you'll set objectives for time to resolution for example. Neither of these are inherently bad.  But you have to be careful. KPIs often lead to undesirable outcomes, especially if people (managers and/or employees) are incentivized by the KPI. In software, if you measure teams on the number of bugs, genuine issues with the product are "working as designed". Customer service will close cases as soon as they respond even if the issue isn't resolved from the customer perspective. You essentially change the behavior of employees to meet the KPI but at the end of the day, your customer (internal or external) isn't benefitting from the changes. Then in 6 months when customer satisfaction is down, the KPIs are changed to try and achieve that objective. And the cycle continues on and on. ... View more

@KoryKramer Let me know if you need a separate idea for "Include column header when copying selected cells". "When you say you want to copy to clipboard, what do you need to do with the copied cells afterwards?" Answer: Paste into Excel, Word, or Outlook. ... View more

For what it's worth, in Pro 3.4.3 and 3.5.0, I'm not able to copy the list of domain names to the clipboard (not to be confused with the domain values). ... View more

Esri mentioned the info below in an message about documentation feedback: ArcGIS Pro was previously applying a spatial filter when querying for all rows in a spatial table, which was incorrect and led to fields without a spatial value being excluded. That was fixed in ArcGIS Pro 3.3, though. The behavior across the platform can be inconsistent if the table does not contain unique ID values or if you create a join that results in duplicate ID values, which makes it difficult to state exactly what behavior you will encounter. That is why we opted for the general statement about the unique ID requirement. That said, though, I notice that the page on which you commented does not include the statement about the unique ID. I suppose it wasn’t called out because all layers—not just query layers—must have a unique ID. But I think we can add a bullet to the list of things to keep in mind and link it to the unique identifier fields page. Other things that would prevent you from seeing all the rows are mentioned in each page about creating a query layer. They’re the spatial property settings. I’ll see if I can work in a bullet about those too. @JonathanNeal, should this idea be closed? ... View more

I am also seeing the problem still. I'm not able to help with troubleshooting either, as I have moved to a different position. ... View more

Yes, I’d settle for that too. ... View more

@AlfredBaldenweck The clause mode is blank:   ... View more